Technical Bank

I came across this weird scenario wherein we were migrating old legacy project coded in Vb.net into Sitecore. So during this process, we had to migrate in a prioritized manner which made difficult to share analytics across two different projects. So I have just noted down what I did in order to accomplish the same. Assume we have a scenario with two different projects which are utilized for same Website (Some pages in Sitecore and Some pages in any other framework ). Let's Assume Sitecore Project named as " CodeYourWaySitecore " and other project named as  " CodeYourWayLegacy " For  CodeYourWaySitecore  and  CodeYourWayLegacy  (“ CodeYourWayLegacy.demo.com ” and “ CodeYourWayLegacy.demo.com ”)  are hosted on different websites.   By default in session, analytics work for each individual site.  Identifying and merging contacts at the end of the session allows for post-session interactions(assuming the contacts have been identified) but does nothing to add

The preview functionality within Sitecore can be a useful tool when viewing pages on your website regardless of published status. Using preview allows you to: View the past or future version of your website based on a specified preview date and publishing restrictions. View a webpage in different language versions. View how a web page appears on various devices. A Note on Sitecore Preview : Pages may not always appear correctly within Sitecore Preview. Keep in mind that previewing will display page content regardless of publish status. This encompasses all associated items, including media. Preview From the Content Editor If you’re in Sitecore’s Content Editor, you can open Preview by first selecting a web page item that you would like to preview and then click “Preview” within the Publish group on the Publish tab. Sitecore Preview from Content Editor A preview of the page item will open in a new tab. Sitecore page Preview  Alternatively, the preview

Must Read  before Reading this Post : Some of the time-saving tips every AngularJS user should know !! - Part 1  . As Discussed in Earlier post  ,It was all about High/Architecture level Tips . Let's go through some Low-Level thoughts. At a Low-Level Thoughts/Tips/Gotchas: 1) Learn and love your console logs - Sometimes, especially with the digest cycles and angular lifecycle, it's sometimes easier to print your debugs to a console.logs instead of adding breakpoints. It's faster! 2) Get Batarang  , the chrome extension -   That is by far the best way to get into the bowels of AngularJS, and some of the details it provides (performance, dependencies) will make your life super simple and easy 3) Start running your unit tests on every save -   It will do the work of the compiler, and next time you break any functionality, you can fix it with a simple Undo in your IDE 4) Use the [] notation for listing your dependencies -  That is angularA

Having worked on and with AngularJS for short period thou , here are some of the time-saving tips at the top of my mind , Just go ahead and comment out if you find it wrong or if you have any : At a high / architecture level: 1)   Write your tests ! - Stop, right now.I mean it !!!. ;)  Don't Ever go by this Saying !!! You can never be 100% right Always write your unit tests. In Javascript, you don't have the compiler to hand hold you and tell  you did something wrong.  And you will want to pull your hair out the next time your app is broken because of a missing letter.And the larger your application gets, having the comfort of making large scale changes and refactorings without worrying about broken functionality is amazing! And writing your unit tests is the only way to get there! 2)   Don't put too many things on the scope .  The scope is expensive, as it is the one that undergoes dirty checks. Just put exactly what will be displayed on the UI

As websites, web applications, APIs, and services become more and more critical, it's import to design and build applications so that they scale well with a large number of requests. To actually test and verify the behavior of services under load, testers and developers can perform load and stress tests. For web applications, a load test would usually involve defining, writing and running test scenarios. A test scenario could be a script that simulates the behavior of a typical user across multiple pages of a website or web application. Once you defined your test scenarios, you can execute it by simulating many concurrent virtual users and monitor how your application behaves. Likewise, for APIs and other services, the idea is to generate requests that are as realistic and similar to a possible load of your production environment, so you can optimize and scale your application and services based on accurate and realistic data. There are various tools that you can use to build, co

There is a thin line between a ScrumMaster and a facilitator. A ScrumMaster doesn’t need to work on the user story or design solutions, but he or she should understand user stories, technology, and the people behind the project in order to become a better ScrumMaster. ScrumMasters are not event managers. Rather, a good ScrumMaster will remove impediments, and a better one will prevent the impediments from forming and affecting the team to begin with. How?  Start the day the right way Many who manage projects are tuned into their day on automatic pilot: They open the laptop and stare at the screen, usually reading their emails. Why? Because that is how we connect to ongoing work from where we left off yesterday. In order to become the better ScrumMaster, leave your seat and meet with the people around you. Team members, extended team members, and colleagues will ask us whether we've seen or read a particular email. Our answer will be no, but we can listen to their issues through imp

Imagine how great (and maybe mildly spooky) it would be if, every time you were about to make a bad decision, someone would materialize out of the mist and say, “Whoa, there, let’s stop and reconsider this.” Thanks to Gilberto Urueta Sanroman and his article at Scrum Alliance, you may not need such supernatural assistance to avoid mistakes in scrum. He compiles a list of 10 scrum mistakes for your team not to make: Scrum Process Too many tasks in progress Behavior-oriented management Not having a clear goal Making decisions for the team Focusing only on efficiency Trying to centralize control Missing visualization No team-building activities No environment in which to fail Forgetting about quality Heeding the Mist Whether because stories have not matured enough or the deployment system is not ready, tasks can pile up, and if you proceed into the next sprint taking on new stories while the old stories are largely incomplete, you can bet  no one  is going to be happy in the end. Sometime