For me there are different types of work-related stress and different people cope differently. I generally see stress as good stress or bad stress, and what type of stress exists in a work environment is usually a function of the prevailing culture in the organisation, which in turn depends on management. Good stress is usually self-imposed, and usually comes from wanting to achieve something, not because you have to, but because you want to. On the other hand, bad stress stems from fear or apprehension or insecurity - for instance, feeling you must do something to impress an oppresive boss or to keep a big client happy. For me good management is about creating a work environment where positive stress dominates. Individuals in such an environment would achieve more - both in terms of quality and quantity. Personally if I start to feel stressed in a job, I know there is something wrong - either with the way I see things at the time or the environment. And if I can't do something to change that situation I generally quit as I value my sanity far more than any job, business deal or money. So @tommyjune my way of dealing with stress is to try and prevent it in the first place - both for myself and for the people that work with/for me.

Just watched a video on Go and looked at their website and it seems a very interesting proposition. I need to write a very small 'agent' type program in C++ but am wondering if I could do this in Go instead ? I'd really appreciate your views on this. Also @rajkumarpb - how is your experimentation going ?

I must be missing something here. Who develops a product and imports a whole javascript 'library' to left-pad a string ?

RethinkDb appears to have great promise, especially in its ability to push changes from the DB towards the client - which should make it perfect for the so-called 'reactive programming' paradiym. Why don't we hear so much about RethinkDb compared to other document stores like CouchDB and MongoDB ?

Just watched this video where they're making some quite interesting claims about server 2016. https://channel9.msdn.com/Events/Ignite/2015/FND1551 I think it's a ploy to retain (or at least not lose) market share by luring people into their cloud platform, Azure. Having said that, I'm quite tempted to try it out !!

No.

Hi, this is looking good. I like the structure and clarity of your code. Just looked at a couple of methods - do you mind a comment or two ? if (className.indexOf( ' ' ) !== 0 ) { var arr = className. split ( ' ' ), i = 0 ; for (i; i < arr. length ; i++) { i) perhaps no need to use strict equality since indexOf returns an int ? ii) if the class is an empty string, the test will return -1 and you'll enter the loop - perhaps not intended ? iii) var s = 'onlyoneword', a = s.split(' '); a is now an array with a single element - so perhaps no need for the indexOf test, but instead test string length ?

Yes and no. Yes, if this is a crucial requirement and you need to do this often, and the benefits outway the downside of writes being slowed down by this index. No if this is something you don't use too often and the benefits are small compared to the hit in writes that will be incurred, or if you can achieve the same result without using an index. In any case, experiment and see if things work better - if they don't then remove the index.

Thanks for invite and sorry for the long post ... Without knowing a lot about your projects it is hard to be specific. However if you are at the ideas stage and are looking to create MVPs then use the technologies you know and are most comfortable with - these can always change if the project(s) succeed. However, if you are working for an established company and have enough resources, know-how and time then you can go down the route of investigating the best long term solution - starting with some proofs of concept, for instance. A key distinguishing feature between relational and current NoSQL products centers around the SQL Join. With relational databases the objective is to abstract objects into groups of very similar data (tables) avoiding data duplication as much as possible (normalisation) The objects are then re-constituted from 'related' data (hence relational) from the tables. For instance, modelling a company, we could have tables for People, Roles, Departments, etc Roles will have a link to People, so we would have to 'join' Roles and People to find a list of people that occupy a role. NoSQL systems approach things differently. The basic principle is that instead of breaking up objects to then re-constitute them using 'joins', why not just store all related data inside one structure and avoid the 'join' altogether ? Most of the advantages and disadvantages stem from this difference in philosophy (approach) For instance, it is easy to shard NoSQL systems since the data for any one object is (there are exceptions) already in one place. Whereas can you imagine the technical difficulty involved in trying to 'sql join' tables that are spread accross several servers (possibly in different parts of the world) ? ACID properties are often mentioned. Relationals provide ACID as a matter of course, but noSQL systems are evolving as well - for instance, MongoDB now provides ACID properties on a per document basis. Even so, using so called 'micro-arhitecture' approaches, this becomes less important. As for querying, this shouldn't be a deciding factor as many NoSQL systems now provide their own querying language. The only problem I see is that there is currently no standard for NoSQL query languages. So if you chose CouchBase, you'd have to use their N1QL languages which is quite different from the querying language offered by MongoDB for instance. Note: I have mentioned only document stores so far, but there are other types of NoSQL databases as well. Specifically, you may also want to consider wide column stores like Cassandra, key-values stores like Redis, etc It all depends on the data you are capturing and what you want to do with it.

As much as I agree with @JanVladimirMostert, I also totally agree with the sentiments expressed by @lorthirk and @fibric. Writing good code starts well before a single line of code is written. Environmental factors like the 'culture' under which people work (eg a culture that favours well understood code that can be defended to peers versus a culture that favours a non-thinking implementation of dictum from some 'architects' above) are likely to produce very different end results with 100% coverage. Test coverage can do only so much to mitigate against badly designed systems, cut-and-paste programmers or ones whose objective is to get something 'to work' without necessarily understanding why or how. Testing is great, but writing good code in the first place and then testing is even better, I would argue.