function Foo(){
    this.name = 'Foo';
}
var f = new Foo();
f.name // => Foo

The above code pretty much says that you first create an instance of the constructor function (note the upper case first letter, this is a convention, not a rule ) using new operator, once that statement executes you now have an object as the value of “f” and in next line it simply prints the “name” property of that object, which in this case is an instance variable of the constructor function “Foo”.

Consider below example and guess what will be the value of “f”:

function Foo(){
    this.name = 'Foo';
    return 'Foo';
}
var f = new Foo();
f.name // => Foo

Interesting thing is that in this case the value of “f” is still an object, but we did return a String, so why the hell “f” contains an object? Well, the purpose of the new keyword is to ensure that you always get an object, so anything other than object is discarded, if you return an object then that will be used else a new object is created and returned. So, if we replace our return statement using the following code then the value of “f” will have a different value altogether and accessing “f.name” will result in “undefined”:

return { prop: 'Foo' };

Interestingly, if you return “null” then that will be NOT be used, even though you might think that null is an object and “typeof(null) === ‘object’“, so it should use that. In fact, it does not, it appears that new returns only objects which can evaluate to truthy value.

Another thing is that if you return a function other than object then the function will be used, the reason is functions are objects too, only difference is that they are special objects, that’s why there’s a separation between objects and functions, the typeof operator handles that properly, but in this case it appears that the new doesn’t bother about that.

So, this is what the new operator does in JavaScript, if you have anything else to share please feel free to comment.

ECMAScript has an abstract concept called “execution context”, which means when control is transferred to the ECMAScript executable code, the control is then entered in a execution context.

So, what does the above statement mean? Well, it means every time a piece of code is executed in ECMAScript it has an execution context and the currently executing code is associated with that context. This can be conceived as some sort of container which encapsulates the context of the executing code, the could will look for its execution context for identifier and scope resolution. The execution context is not accessible to code; it is purely an implementation mechanism.

Active execution contexts form a “stack”, the bottom element of that “stack” is always the Global Context, where as the topmost element is the active or current execution context; whenever the control is transferred from the currently running executable code to a different piece of code which is not associated with the current execution context, a new  execution context is created and pushed onto the stack. The process of creating and removing execution contexts from the stack is a continuous thing.

Why execution context is so important? It is because execution context maintains the state  and execution progress of the code. It also determines what should be the value of the ‘this’ keyword associated with that execution context. The identifier resolution is also an important part of the execution context, because it is the mechanism which specifies how the binding of an identifier will be resolved in the current/active execution context. To put simply, identifier resolution is a process which determines how the JavaScript engine will retrieve the value of a particular variable and where it will look for.

The execution context is associated with the type of executable code. In JavaScript there are three types of executable code:

1. Global Code is the source code which is executed as ECMAScript program, for example – external JS file, inline script block in HTML pages are executed in the Global Context. So, when a global code is executed a global execution context is created and pushed onto the context stack.
2. Function Code is the source code which is parsed as the FunctionBody. The function code does not include body text of the nested functions. Invoking a function creates a new execution context every time, even in the case of recursive execution, and when the function returns, the corresponding execution context is popped up from the execution context stack.
3. Eval Code is the code that is the source text supplied to the built-in eval function. Eval code has a concept of calling context, which means the execution context from which the eval function has been called.

What happens when an execution context is created? A number of things happen when an execution context is created, if the type of code being executed is a function code then an “Activation Object” is created. Activation Object is a normal object without any prototype, which contains named properties. It stores information regarding variables and call arguments so that those are accessible to the execution context.

There’s more to execution contexts like scope chain, variable object and variable initialization. All of these I’ll cover in later posts. I assume the above explanation will serve as a primer on how the JavaScript engine works internally. Please do share your thoughts on this.

Update: For more detailed information on Execution Contexts check out this in-depth article written by Dmitry A. Soshnikov JavaScript Execution Contexts, do not forget to go through other articles written by him, those are an excellent source of information on JavaScript/Ecmascript internals.

Well, as you might think that I’ll be talking about how to implement border-radius across different browsers, which in fact I don’t intend to do, as there are already a plenty of good examples that you can find if you do some Googling. Recently, I was playing around border-radius in different browsers and I came across some inconsistencies, which I want to document it here, I am not sure which implementation is correct in this case but it looks like some browsers have identical implementation while others have a slightly different one. Below is the screenshot of images and how all looks in browsers in different conditions, I’ll show the code and how that works across browsers.

Basic styles for the box that I used in my tests:

  
  #box {
  margin: 100px;
  width: 250px;
  height: 100px;
  }

Applying equal border-width and border-radius

 
/* basic border styling */
  border-width: 20px;
  border-color: red;
  border-style: solid;
  /* Mozilla Firefox */
  -moz-border-radius: 10px;
  /* W3C, Opera and IE9 Preview */
  border-radius: 10px;
  /* Safari and Chrome */
  -webkit-border-radius: 10px;

After applying the above styles the border on all four browsers look something like below:

As you can see in the picture above, the box has given an uniform border-radius and border-width to all borders. It appears that Firefox, Chrome and IE9 all have identical behavior/implementation, only Opera seems to have screwed it up, by the way Opera handles it fine if the border-width value is smaller; in my test I set it up 20px to have the borders more prominent, so that it becomes easier to see the effect.

Applying variable width and radius to different borders

 
border-width: 1px 1px 20px 1px;
border-color: red;
border-style: solid;
/* Mozilla Firefox */
-moz-border-radius-bottomleft: 10px;
-moz-border-radius-bottomright: 10px;
/* W3C, Opera and IE9 Preview */
border-bottom-left-radius: 10px;
border-bottom-right-radius: 10px;
/* Safari and Chrome */
-webkit-border-bottom-left-radius: 10px;
-webkit-border-bottom-right-radius: 10px;

Similarly after applying the above styles the border on all four browsers look really different. I must say that IE9 and Firefox have similar implementation whereas Chrome and Opera is completely different. Here’s the image:

Another example this time with right borders:

 
border-width: 1px 20px 1px 1px;
border-color: red;
border-style: solid;
/* Mozilla Firefox */
-moz-border-radius-topright: 10px;
-moz-border-radius-bottomright: 10px;
/* W3C, Opera and IE9 Preview */
border-top-right-radius: 10px;
border-bottom-right-radius: 10px;
/* Safari and Chrome */
-webkit-border-top-right-radius: 10px;
-webkit-border-bottom-right-radius: 10px;

Here is the image:

As you can see even though all the above mentioned browsers have implemented border-radius property still there are variations in implementations. I am not sure which implementation is technically correct, but Firefox and IE9 seems to have more elegant solution than Chrome and Opera. I would like to hear more from you regarding this, please do comment if you have noticed any other problems with border-radius.

Here’s the HTML code that I used for my tests http://gist.github.com/350379

As there’s no way to target other browsers using conditional-comment like thing then how would you do it if you ever(though unlikely) have a need to serve different CSS files to some of the modern browsers? Well, seems like I have a solution for you. Recently, I stumbled upon a code while doing “view source” (I do it all the times and have found it pretty useful), which had something different that caught my eye on. I don’t know whether this is a well documented or a known thing, but this is something I have never seen before, so I thought it might be a good idea to document it here, in case it helps someone. By the way, keep in mind that this only works in Safari and Chrome as because both browsers share the same rendering engine, so assuming that all webkit based ones will have the same behavior. Opera, Gecko and Internet Explorer do not exhibit this behavior as I have found.

It appears that webkit ignores “text/css” value of the “type” attribute of <link> tags as long as you have “rel=stylesheet”, I assume that it depends on mime-type instead of the type mentioned in the tag itself. The following code will load the stylesheet file in Safari/Chrome but none of Opera, Gecko(Firefox) and Internet Explorer( 6, 7 and 8 ) will even load the CSS file:

<link rel="stylesheet" href="/style.css" type="text/safari" />

<link rel="stylesheet" href="/style.css" type="text/chrome" />

You can have anything in the “type” attribute like “text/mycss” or “text/webkit” all will work. By the way, removing the “type” attribute loads the file in other browser’s too, so to prevent that you got to specify something different albeit an incorrect type. This is a bit whacky or clever way to target webkit specific browsers.

Finally, the question is that do you ever really need this ? I don’t think so, mostly 99% cases you don’t need to target webkit browsers specifically, they have an excellent support of web standards and my experience says that most of the things just work out of the box in webkit and gecko. So this tip is for that 1% edge cases where you might need this.

I tested the above code in Firefox 3.6, Safari 4, Chrome 4, Opera 10.50 Beta and Internet Explorer(6, 7 and 8).

Just so we’re all on the same page, “chaining” is this wonderful functional property of languages like JavaScript (which treat a function as a first-class citizen). It essentially amounts to making a function call, and the return value from the function is itself either another callable function, or more often, an object that has functions which are directly callable

Check out the article http://blog.getify.com/2010/02/simulated-chaining-in-javascript/

Below are the list of things that I would expect to see in a would be frontend engineer:

• Semantic and non-semantic markup – Understanding the differences between semantic and non-semantic HTML is a key area in web development, in HTML we have different tags with different semantic meaning, a frontend engineer should know which tag to use when, it’s not a good practice to use <DIV> tag to display paragraphs even if both <P> and <DIV> visually look similar.
• Rendering modes – Every browser for the sake of backward compatibility has implemented two types of rendering modes, and browser’s use DOCTYPE tag as the rendering mode switcher. It’s important to know about rendering modes because they drastically affect the way browsers render a webpage. Primarily, there are two rendering modes “Standards mode” and “Quirks mode”, some browsers even have “almost standards mode”. In “standards mode” browser will try to display a webpage in the most efficient way possible, where as in “quirks mode” browser will display the page in a backward compatible way.
• Structure, presentation and behavior – These are the key design elements in building websites. The structure (HTML), presentation/styling (CSS) and behavior (JavaScript) should be separated out, which helps make you page modular and maintainable. Remember it also speeds up your site, because the presentation and behavior layer will likely be cached by the browser, which results in faster downloads. Use meaningful markup with Class and Ids as the possible hook for adding styling and behavior. Never use inline event handlers in your HTML, instead use Unobtrusive JavaScript to attach event handlers, which helps keep the markup clean.
• Ability to hand code your HTML – There are some WYSIWYG editors out there in the market, but I would recommend not to use any one of them, instead learn to write HTML by hand coding, because this will give you the ability to create a visual picture of your page layout in your mind, if you continue this practice after some time you will notice that you can almost tell how many DIVs you need to create a particular layout just seeing that design. Remember that all those big web applications out there were created by hand coding HTML and CSS, once you are proficient writing HTML then you can use some code auto-completion utilities to speed things up a little bit.
• CSS and browser quirks – The CSS stands for ‘Cascading Style Sheets’, here ‘Cascading’ means a way to determine which CSS rules are going to apply on a particular element. So it’s important to know how Specificity, Order, Inheritance and above all the Box Model are being calculated. Some browsers have terribly wrong implementation of some CSS standards so it is important to have the knowledge regarding browser workarounds, there are CSS hacks and fixes available for some browsers most notably Internet Explorer, which you can use or you might consider using conditional-comments as a way to include special style sheet for that depending on your needs. Another thing in this context is the knowledge regarding ‘hasLayout’ concept in IE6/7, this concept is one of the main reasons behind CSS bugs in above mentioned browsers.
• JavaScript Language – Learn this language, it’s no toy language anymore and it’s not even distantly related with Java excluding the naming similarity. It is an Object-oriented language with prototypal inheritance pattern. This is the language which drives modern day web applications, since the advent of Ajax this period has seen a tremendous growth of JavaScript. I believe that the way HTML 5 is heading this language is going to be one of the most important programming languages in the next decade. JavaScript was designed in a hurry, so there are some rough edges and some incorrect implementation, hence it’s important to know the good and bad parts of the language. In modern web applications JavaScript interacts heavily with DOM(Document Object Model), so having a good understanding of DOM methods, traversal techniques, DOM manipulation are necessary. I recommend picking up Professional JavaScript for Web Developers.
• JavaScript and CSS Frameworks – Once you are well familiar with all the above concepts, it’s time to pick up few JavaScript and CSS frameworks. Nevertheless, the JavaScript Frameworks that you should check out are jQuery, YUI and Dojo etc. and for CSS Frameworks there are OOCSS, 960.gs and Blueprint etc.. Even though you can go through with those libraries, I would recommend you should go through their source code whenever possible, this will give you a lot of insight into what’s happening and how those libraries have organized their code, you’ll learn a lot, I guarantee.
• Website Optimization – This is a very important point, and you just cannot ignore it  anymore. Latency is one of the main reason behind slow websites, but you can do very little about it, so focus on areas where optimization can give you significant result. Learn how to cache your assets using proper HTTP headers, serve your assets using Gzip, optimize images (there are some good tools around one example is SmallerMaker ), know how browsers do parallel downloading, consider using ‘Lazy Loading’ techniques, load scripts on-demand/on the fly when required and use CSS sprites where suitable(although you can take a peek at Data URIs). For more info check out stevesouders.com.
• Staying up-to-date – The frontend technologies are changing almost everyday, so it’s very necessary to stay up-to-date, you got to keep an eye on the stuffs happening around JavaScript, HTML 5, CSS3 and other best practices, which will help you gather information and knowledge upfront, which you can later use in your work.
• Communication and co-ordination – Last but not the least, this is a very important job that a frontend engineer has to do everyday with his peers, managers and creative designers. He/she has to communicate well in terms of what can be possible in the browser, how changing something can improve or degrade accessibility or performance. I have seen designers often like to design interfaces by pouring every bit of their creativity and aesthetic sense, which is a good thing definitely, but in a real world implementing those interfaces using HTML/CSS is sometimes impossible, hence it is the frontend engineer who should actually communicate with the designers about what can be done and what can not. In some cases he/she often has to push back some features which might introduce too much complexity or impact the performance of the application as a whole, and while doing so I would expect that a good frontend engineer to come out with alternate solutions in a constructive way. As frontend engineers sit somewhere between middle-tier, creative and product management, so their efforts are directly related with these people, communicating and coordinating properly will definitely serve well.

Well if you want to be a frontend engineer make sure that you know stuffs I mentioned above, these are just the beginning by the way, there are a lot of things that you will learn eventually, but don’t forget to make sure that your base is strong, do a lot of practice, ask questions, read articles and blogs and finally think like a frontend engineer. All the best.

Disclaimer: The use of the word ‘engineer’ is not meant to do anything with ‘Engineering discipline’ at al, I know traditional engineers do a lot of hard work to achieve that academic qualification, as working in frontend also involves similar amount of hard work that’s why the term has been used here to refer the collective effort of those people.

LABjs’ primary goal is to replace the “<script> tag soup” in your pages (you know, all that garbage that clutters up your <head> or the end of your <body>) with a simple and expressive API that gives you complete control over the loading and executing behavior of your scripts.

Check out the full detail here http://blog.getify.com/2009/11/labjs-new-hotness-for-script-loading/

Updated: Post updated to include the name of Kyle Simpson the primary author of the library.

The three things that I would like to touch upon in this blog post are below:

1. Planning and proper understanding of what to build.
2. Technology and architecture
3. Employee management

In India start-up software companies begin with a very novel idea and most of them are novel indeed, but the number of ideas we have and the number of successful results we get at the end of the day differ a lot. So what are the problems why so many start-ups fail miserably, what are the common mistakes they all make, and how they suffer? To find answer for each of these questions one needs to carefully analyze all the efforts that have been made in order to make that idea a real thing, often we see that entrepreneurs talk about a certain idea which they think is something big and has the potential to change the world, but in reality most of the time those ideas are based on limited market research, inadequate domain knowledge and a lack of practicality which includes very limited understanding of users’ need. Here I am trying to express my views regarding the points mentioned above that any would be entrepreneur should be careful about, because these are the things that matter most if you are in a high-tech industry, which is distinct in every essence than other industries. Innovative idea with proper approach is what makes you stand out among the crowd at the end of the day.

Planning and proper understanding of what to build

In start-ups the actual planning started in most of the cases with some ideas and a limited discussion around it, in rare cases it’s being documented, the discussion happens around how many screens are there, who is going to do what and how quickly we can build, if you are in a real hurry and want to earn huge money as quickly as possible then you probably are not a true entrepreneur or you are one of those greedy people to whom only money matters, remember there’s no shortcut to glory, you got to work hard.

Engineering your dream is not just bringing a US bound guy on board without judging his technical capabilities, that whether his expertise aligns with your vision properly or not, you really need a very technical person with a lot of domain expertise in building stuffs that you want, who will work as your advisor and also as one of your trusted partners while building your dream. You need a real engineer in this case.

Research is to see what everybody else has seen, and to think what nobody else has thought – Albert Gyorgyi

I think when you are out to build a start-up, you need to do a good amount of research about your target market, yes I mean it, and it’s a serious thing. You need to do proper analysis. I sometimes wonder that how someone can start building products without analyzing the market, you need to be sure and backed up with statistics that indeed there’s a need for your product, don’t just read some articles and start assuming that there’s a big potentially huge untapped market for your product, watch your steps dude!. A good approach can be to identify some of your target users, engage with them, get their feedback on the problem that you are trying to solve, give them multiple solutions, see which one suits them well. Start with your market before building your product. Try creating product documentation, PowerPoint presentation, and prototypes (it’s a must), get a clear understanding of what you are trying to build, bring your vision into reality slowly and steadily, I know entrepreneurs don’t like the word ‘slow’ but remember “Slow and steady always wins the race”. Having a prototype before you build the actual product is pretty important because it can help you see that how people will interact or use your product, if you don’t find the prototype compelling enough for yourself then think again before investing your fortune.

When you are out to achieve your dream, you should keep in mind that most of the time you have limited resources, so precise planning and careful usage of your resources can yield you pretty satisfactory results, and the most important of all is to have a clear understanding of your goal, and a path to that. “Rome wasn’t built in a day” – so plan an incremental program, be realistic that how much you want to achieve in a certain version, then further break it in multiple iterations, remember the more impatient you are the more the chances to make mistakes which will eventually wash out your dream. Don’t build everything that you have in your mind, instead carefully decide the set of core features, which often is a small set of necessary features, keep them modular so that you can easily pull them in or out, have a good amount of discussion around core features, keep it small and extensible, build the base first. So once you have the first version ready, gather as much user input as you can, ask your friends or anyone outside your company who is not associated with the idea to evaluate your product, consider their inputs because they are the people who are going to use it at the end of the day, incorporate their inputs, keep this practice going until you reach a stable version. Avoid having “too many features”, yes I mean it, having too many features actually confuses the user, so don’t give your users too many choices, don’t even expect them to remember how to use each and every feature that you provide, so having a small set of useful features is good in this case, don’t waste your time building on a lot of features, control your temptation to add as many features as you can or you think can be useful, don’t assume unless you really have the statistics to back you up that those features are indeed necessary. It sounds a cool thing that your application has multitude of features than others, I have seen entrepreneurs brag about it that they have tons of features that their nearest successful competitor doesn’t have, this does not make sense if only 1% of your users are actually using those features. So remember having tons of features won’t help, even if you think you want to have those then build your application like a platform and allow others to build the missing bits on top of it.

Lastly, I would like to say that don’t just copy what others have built, remember copying won’t help, for example if you copy Facebook or Twitter and thus assume that your application will be a great success, then you are simply ignorant, or just don’t understand how web works. It’s like selling a car which has its engine from Ferarri, chassis from Honda and other accessories from different vendors and you think that you have built a great car and people will buy it like crazy, nobody will because it lacks originality.

Technology and architecture

The technology defines a product; it is the underlying system which works to make sure that a user of the system performs his desired tasks gracefully without much hassle. The aim of the system should be to aid the user to achieve his target, it should not come into the way of users to do their stuffs, a system should be designed to make a complicated task simple, and it’s of no use if the system itself makes a simple task even more complicated instead of doing the other way round. When designing a scalable architecture you should keep in mind that modularity is your way to go, there should be a clear separation of the parts which makes up the system as a whole, this greatly reduces the maintenance hazards in long term. I understand that when you are building a system there will indeed be dependencies, but there are lots of cool ways you can handle it, read DI (Dependency Injection) or consider picking up “Design Patterns – Elements of Reusable of Object Oriented Software”.

Choosing the right architecture is equally important while designing the system, a wrong choice can put you in big pain at the beginning and a careful consideration regarding the right technology will save you a lot of dreadful nights. Consider a matured Open Source technology backed up by a vibrant community.

Another thing regarding designing the architecture, remember it is not just designing the Database only and if you think database normalization is the only thing then this is the first sign that you are going to be in deep shit sooner than later. The whole architecture depends on the application design, modularity and extensibility, if a system was not designed to be extensible then it’s doomed to be a failure. I have noticed some conceptual problems where people think that the scalability and stability of the system depends mostly on hardware than on software, they think that the more hardware you have the more faster your system will be, which is just as wrong as to think JavaScript is a subset of Java. If your system was designed to be modular then you can plan for better QA, don’t try to finish things as quickly as possible which often results in error and reimplementation of the same, some people try putting more resources to finish things quickly, remember one simple example – “it takes 10 months to have a child, if you put 10 men or women, that does not mean that you can have a child in one month ”. Have a proper review process, reviewing and thus maintaining quality is very important for a system to evolve, and a serious introspection can often find a lot of errors even before writing a single test case.

If you are building a web application, you must have a browser support chart in place while designing the system, if you don’t have one then it is a sheer example of improper planning and a recipe for the disaster. One of the pain-points in modern web development is supporting IE6, do a little upfront research regarding your target users browsing environment, if you think you need to support IE6 then plan accordingly, but please don’t change course in the middle, don’t just decide to start supporting IE6 in one fine morning, you should consider doing the cost benefit study before supporting IE6, if that suits your financial model then go for it else decide upfront what to do. One option that you can follow is “Progressive Enhancement”.

Last but not the least, if you are using some well-established open technologies there you may find some way to customize it, then keep the customization as minimum as possible, never try to use the ability to customize as a tool to change the behaviour of the open system, don’t just unnecessarily add proprietary extensions to it, if you can’t make it work properly, then do a research that how others have done it and what’s wrong in your approach. I have this experience before where I have seen people changing XMPP protocol in such way by adding lots of proprietary extensions to it and that it has eventually become a massive pile of shit and it can no longer be called XMPP and the funny thing is that if you implement XMPP it is normally assumed that the existing XMPP clients can communicate with your system, but in the above mentioned case that system actually broke that compatibility, so the lesson is just don’t do that. Remember what the Zen of Python says “There should be one– and preferably only one –obvious way to do it.”

Finally a bit about Application Security, when you are building a system which will store user’s personal data then you must make sure that your system is secure, remember security is an important thing, because users trust your website that you will respect their privacy. Ask your programmers what they know about security, you might be disappointed that how little they know but tell them to learn the best practices. Don’t implement “Security using obscurity”, this does not work. Make sure that your system does not have any “SQL injection” hole, if it’s a web application consider preventing XSS, Session/JS Hijacking scenarios, another example if you are using Flash crossdomain.xml, beware that this can expose your website to variety of attacks.

Engineering is not making a perfect solution, but doing the best you can with limited resources – Randy Pausch.

That’s it regarding technology and architecture, a robust application design can benefit you from lot of ways, so take your time to design, do proper research prior to it, hire right people and carefully use your resources.

Employee Management

This one is a bit tricky, I wanted to avoid talking about it but without this it looks like incomplete, so let’s read on. In start-up companies initially you will see people digging into technologies, learning new things, trying to do stuffs that they always wanted to do, almost half of them are the right set of people that you need, not everybody wants to work for a start-up by the way and those who work have at least the mindset to work for a start-up, so keeping those people motivated and nurturing them is the only way to build a start-up workforce as I think. Start-ups are known for “Open Environment”, “Flat Organizational Structure”, which is very crucial for the growth, and this structure needs to be maintained all along till your company is a start-up. Don’t try to bring hierarchy in your “twenty” people company, geeks often find hierarchy very annoying.

Let the programmer be many and the managers few — then all will be productive – Tao of Programming (http://www.textfiles.com/100/taoprogram.pro)

People usually work hard in start-ups and they deserve recognition for that, so if you see that people are working hard for you then encourage them and give them the recognition that they deserve, don’t just piss them off saying that you stay late in the office so it means you can’t finish your tasks in time, which is in reality a big lie and enough to demotivate that person. Treat your employees properly and if you hire someone then give him some time to get used to the system, plan for some sort of training for new joinees. I saw once that my company hired a young fresher in my team(without discussing with me) and gave him an HTML book to read and the very next day assigned him some bugs to solve, then I had a talk with that guy and learnt that he never had done HTML in his entire life and he then needed to solve those bugs, this incident just made me surprised, this isn’t the way to treat your employees, I saw a lot of dreams into his eyes but I knew that some of them are going to be crashed because he landed up in a wrong place for the very first time in his career, I feel bad for him, so my advice to those entrepreneurs who do this kind of stuffs that don’t just break the dreams that people have think that you have created a start-up to achieve your dream similarly others do have their own dreams, don’t break them, if you can’t help then don’t hire, don’t be a jerk. Here is a small solution that I have come up with if you have freshers working in your company and don’t know whether they are improving or not, then ask them every month that what are the new things that they have learnt in last month, verify their answers, this will make them learn new things, which in turn is a good thing. Plan some sort of tech talks every two weeks, which will create an environment of sharing knowledge. Lastly, the psychological well-being of the employees is very much important for the company’s work culture and long term benefit, forcing them to work hard late night will soon burn them out, which results in quitting, exploitation can’t work for longer period of time, entrepreneurs should understand this.

Okay, that’s it; it has become a long post, if you have come to this very last paragraph then I personally thank you for your patience and the time you took to read this post. All the above things are my thoughts and here in this blog I like to share the stuffs that matter to me. If you think that my concerns are valid ones then I’ll appreciate if you comment, by the way it’s not necessary. Finally, this post was not intended to hurt anyone; I tried to keep it as constructive as possible, with bits of my own experience as examples. I hope you have enjoyed this. Thanks for reading through this once again.

Employee Life-cycle at Big IT firms in India

Hope you have liked it , by the way the above post is not meant to heart anyone’s feeling, chilax…

“Bomb!!! are you kidding or it’s just another bad joke from you?”

“Wait wait it’s not, instead it’s true that Google did drop a bomb but it’s not similar to normal bomb that you and me have seen in the movies, it’s a different one… yes it’s a different one and it’s called Chrome Frame. You might be wondering what’s this, no worry just have a little more patience you will get to know what it is.”

Nuff’ said… let’s explain what it is all about, Chrome Frame is Google’s effort to kick Internet Explorer in it’s arse, yes in it’s arse, in fact in Microsoft’s arse, this is a simple plugin( yes simple from User’s point of view) for Internet Explorer(6, 7 and 8), which does a “cool thing“, it replaces IE’s decade old, shitty rendering engine a.k.a Trident with Google Chrome’s high performance rendering engines ( Webkit for HTML-CSS and V8 for JavaScript), so once you have installed this plugin you can have Chrome’s super fast rendering engine inside IE. Isn’t this a real cool thing?? By the way it’s still in beta and the awesome thing is that it’s OpenSource. This is what our Alex Russel ( Creator of DOJO JavaScript Library ) has been doing since he joined Google, great job done.

We all know that developing rich web applications these days is a pain if we need to support Internet Explorer but the crude fact is that we can’t ignore IE because of its market share, which is still more than 60%. And Microsoft is somewhat reluctant or don’t know what, in pushing new developments for IE, so it has become stagnant for some years and lagging far behind in features and performance than other modern browsers. Microsoft did try to fix this in their effort of developing IE8 which is a better browser than both of it’s ancestors, but it failed to gain enough momentum. As Microsoft also extended support for IE 6 till 2014 (Win XP support ends in that year), so there was a real or quick need of a solution which can help developers and users to reap the real benefit of modern rich web applications. So here comes the Google Chrome Frame, which is supposed to fill this gap, until Microsoft fixes it’s browsers or decides to use Webkit and V8 as it’s rendering engine . Recent surveys regarding IE6 market share reveal that almost 70% IE users are not able to upgrade their browsers due to some other reasons for example : old OS, corporate policy, govt policy etc, so this is a nice alternative for them (though Chrome Frame requires Win XP, but it’s still in beta so lets see) and as far as I guess this plugin was intended for big Corporate Houses who still use IE 6  because they have some in-house applications which only works in IE 6 or may b uses IE’s ActiveX controls, so this is a answer for them, now if Google can convince those business organizations about this then we might soon have Chrome Frame installed in most of them.

The Chrome Frame blog and developer’s guide has detailed the installation process and the usage, please check out the below link for more information regarding this:

http://code.google.com/chrome/chromeframe/developers_guide.html

Finally as a Web Developer/Frontend Engineer I’d love to see Chrome Frame in all IE6/7 browsers, because this will surely make my life less painful and I’ll focus more on developing cool applications than spending ‘countless hours’ to fix IE bugs. This is a serious attempt from Google to fix the mess, so now let’s see how much response it gains, by the way I do hope for the best, rest is up to the users and decision makers.

Cheers!!! that’s why I love you so much Gooooooooogle.