Monthly Archives: فروردین 1393

how to update fields of a nested object in mongodb?

Salam (means Hello) :)

I'm using node-mongodb-native driver and I need to update specific fields of objects stored in an array. this is a sample document in my mongodb collection:

{
    "fields" : [ 
        {
            "en" : "birthDate",
            "status" : "enable",
            "index" : 10
        },{
            "en" : "email",
            "status" : "enable",
            "index" : 4
        },{
            "en" : "inviterCode",
            "status" : "enable",
            "index" : 2
        }
    ]
}

and this is my new data:

var newData = [ 
    {
        "en" : "birthDate",
        "status" : "disable",
    },{
        "en" : "email",
        "status" : "disable",
    }
];

as you can see, if en field matches, status field should be updated. I know that following query works for a single update, but how can I achieve multiple updates with a single query?

collection.update(
    {'fields.en': 'birthDate'}, 
    {$set:{'fields.$.status': 'disable'}}, 
    {w:1, multi: true}, 
    function(error, count){

    }
);

how to update fields of a nested object in mongodb?

Salam (means Hello) :)

I'm using node-mongodb-native driver and I need to update specific fields of objects stored in an array. this is a sample document in my mongodb collection:

{
    "fields" : [ 
        {
            "en" : "birthDate",
            "status" : "enable",
            "index" : 10
        },{
            "en" : "email",
            "status" : "enable",
            "index" : 4
        },{
            "en" : "inviterCode",
            "status" : "enable",
            "index" : 2
        }
    ]
}

and this is my new data:

var newData = [ 
    {
        "en" : "birthDate",
        "status" : "disable",
    },{
        "en" : "email",
        "status" : "disable",
    }
];

as you can see, if en field matches, status field should be updated. I know that following query works for a single update, but how can I achieve multiple updates with a single query?

collection.update(
    {'fields.en': 'birthDate'}, 
    {$set:{'fields.$.status': 'disable'}}, 
    {w:1, multi: true}, 
    function(error, count){

    }
);

Why developers never finish their projects?

Every developer starts about 100 projects that never end up going anywhere. So many good ideas, so few executed ideas. Just about every software developer that I know has a folder structure that resembles the one shown. More than a handful of incomplete projects that seemed like a great idea once upon a time. Like many of you, I’ve had many ideas for great products / companies and even started down the path of implementation for some of them. A bot that determines arbitrage opportunities between eBay and Amazon. A social network for referral based businesses (plumbers, electricians, software developers, etc). A bitcoin search engine. A CSS framework for the days when Bootstrap wasn’t literally everywhere. A “hot or not” that found people from Instagram. A real-time visitor analytics engine. The list goes on. I’ve started on just about every one of these projects (and more), but never saw them through to completion. In talking with my developer friends and colleagues, I find that the story is oft repeated. Some folder on their computer that lives as a graveyard to high hopes and incomplete dreams. I’ve wondered why this is. Success as an Obstacle We, as an occupation, are blessed with high employability. Currently, the national unemployment rate is around 6.7%, while the unemployment rate for web developers is closer to 1%. Our salaries are also substantially higher than the average. In 2012, the median income for software developers was more than $90,000, now of course, if you’re any good, you can far exceed that. Having taught complete n00bs before and watching them become entry-level developers has brought me a great deal of personal satisfaction. But it’s also brought them financial satisfaction, with starting salaries ranging from $45,000 to $70,000. So it’s clear that software developers are generally successful. Yes, there are thousands that completely suck. There are many that are not paid well at all and can’t hold a job for very long. But I’m making a generalization here, so allow me the liberty to be general. A halfway decent developer is a relatively (compared to the general population) successful person. This success can paralyze and inhibit the completion of goals, however. We are far from hungry and we’re too smart to think that we can ever be foolish. The impediment of Knowledge We know so much. We can talk about the shortest way to travel between multiple cities. We understand how to take large problems and break them into smaller sub problems. We can tell you the best way to “abstract” whatever your system is into discrete units. We are true polyglots as we can say “Hello World,” in any number of languages. We don’t shy away from situations that might require thousands of calculations since we understand the power of recursion. We know a lot, but is that enough? The great Einstein once quipped: A little knowledge is a dangerous thing. So is a lot. Sir Isaac Newton, one of the smartest men of his time, could accurately predict the movement of celestial bodies so many millions of miles away. He stood on the shoulders of giants to see farther than anyone else had. Physics wasn’t his only interest as he also (co)gave us calculus. Surely he could understand how money and markets work, right? Wrong. During 1720, at the peak of the South Sea Stock Bubble, he threw down a ton of cash and went broke. All of his knowledge didn’t help him one bit, because he failed to understand the dynamics of markets. His knowledge was not domain independent — he was a master of moving bodies, but that did not translate to the psychology of his fellow traders. We too are like that. While we can explain algorithms and data structures all day long, we may not inherently understand what people want. When the twitters first came about, I suspected it was just a fad that would disappear. I was wrong. We often seek sexy solutions without realizing the mundaneness of the problem. Career ADHD I’m sure the same holds true for any major city, but I am speaking of my experience and the experiences of my colleagues and friends in the New York City area. We jump around in our careers. We swing between startup, corporate, agency and “just taking time off.” I realize this doesn’t hold true for everyone, and the trolls of the internet will leave comments with how they’ve stayed at the same job for 19 years, but I have found that those with the passion / interest in having a side project, often don’t stay at one place for too long. I think that this Career ADHD leads to many abandoned side projects. Sometimes a new job starts up and the demands of getting caught up there mean putting the side project on “pause.” Sometimes we lose interest because the side project was aligned with something that we were doing at our previous job. While logistics is a reason that switching jobs every few years makes it much harder to stick to a side project, there is something to be said about the mentality of switching. If you can change your job in 3 years, why not change your side project in 3 months? You’ll have a better idea at (seemingly) the exact moment that you hit a wall in your current side project. Fixing It So I’ve identified a few reasons that I think that I have so many unfinished “great ideas.” Admitting it is the first step. Understanding the reasons why is the second step. Now, for the third step — fixing it. It won’t be an overnight solution and many of my projects will remain forever abandoned, but after thinking through it a bit more, I think I’ve come up with some steps to help this from becoming a pattern. You are Awesome First, recognize that every side project makes you a slightly — or in some cases, substantially — better developer. Your skills are the sum of the times they’ve been applied, so the more you develop, the better you become. Learning new technologies / languages / frameworks is a great reason to start a side project. Even if it never finishes, something was accomplished. So, first realize that you don’t always have to finish every project — as long as you walk away with some gain. Build parts of Projects You’ve started so many projects and, as you got wiser with each, hopefully you learned to reuse code. Building modules and libraries instead of rewriting everything each time. Assume that whatever side project you’re working on now may not be the last one, so you’re better off grabbing components from it instead of of building specific things that ONLY this project can use. Documentation matters, so leave notes for yourself that can be easily applied to the next project. Do it with Others Now that we’ve gone through successful ways to fail completing a project, let’s try to complete some! It may be your brilliant idea, your baby, your future billion dollar empire, but as of right now — it’s nothing. Share it with other people, the more the merrier. The natural excitement will continue to propel the project forward. Maybe you can even open source it, to encourage community participation? Relying on others and having them rely on you keeps you foused and accountable. Solve problems you Have Rather than making your next project an iPhone app that lets you take pictures of food while you travel by bicycle in cities that have cloud cover 43% of the time where the nightlife consists of urban zoos that hold endangered genders of overpopulated species — try to make something that you would ACTUALLY use. If you’re a developer, solve developer problems. If you work for an agency, create something that agencies would like to use (see: 37 signals). Even in your personal life, you invariably have some small problem that technology can solve, so why not create something to solve it? That way, even if it doesn’t actually go anywhere big, at least you built something useful. Size matters, so stay Small Don’t create an enterprise XYZ when the timeframe to do so would be 8 months. Focus on something you can create in 4 weeks, part time. Scale your features back to keep a monthly release cycle, no matter how simple. Having something shipped has a strong psychological component that further encourages you to work on it. Something sitting on your laptop for 8 months that has never seen the light of day is almost depressing to work on. It’s all about the little wins, since the journey is a marathon instead of a sprint. Brag until you Fail Social pressure is a real thing. It’s why skinny jeans became a thing. Instead of working in secret, tell people what you’re working on. The feedback you get might help shape the product. I can assure you, no one is out to steal your idea. It’s extremely hard to execute even a simple idea, so don’t worry too much about that aspect. Share your idea, it’ll validate (or invalidate it), shape it and most importantly, commit you to it. We don’t want to let people down and we do want to save face, so tell people what you’re working on.

Why your previous developer was terrible, And why your current one seems so amazing

You hired a new developer for a project you’re working on and she seems to have solved all of your problems. She’s been on the job for 3 days and she’s already suggested upgrades for 5 of your libraries and re-organized your JIRA issues. At every turn, she seems to validate your choice in hiring her. She’s found 8 bugs that were glaring and would have caused a critical meltdown. How terrible was your previous developer that he couldn’t have spotted any of this?? She’s baffled by his decision to use the XYZ framework and doesn’t understand why he chose to use Postgres instead of CouchDB for this particular application. She complains to you that the lack of a CDN is costing you HOURS in needless content serving. How could you have been so blind to not see any of this? Well, it wasn’t your job, right? That was your previous developers’ job and he seems to have failed miserably. Good riddance. The curse of the present Don’t worry — your situation is far from unique. I’ve seen it time and time again that a new developer comes in and seems to change everything almost overnight. She or he suggests new tools, new processes, new languages and new everything. All of this while badmouthing the previous developer or team. I’ve been on all sides of this fine play. I’ve been the “previous developer” who got badmouthed by the new guy. I’ve been the new guy that used the previous guy as my scapegoat. I’ve hired developers that have been in both positions. I’ve worked for companies that couldn’t see what was plain to me: this happens all the time. It’s what I call the “curse of the present.” When you, as a developer, look at the choices used to build a particular application, you’re blown away at the poor decisions made at every turn. “Why, oh why, is this built with Rails when Node.js would be so much better?” or “how could the previous developer not have forseen that the database would need referential integrity when they chose MongoDB?” But what you may not realize is that you are seeing the application as it exists today. When the previous developer (or team) had to develop it, they had to deal with a LOT of unknowns. They had to make many decisions under a cloak of opacity. You are cursed with the knowledge of the present, so the system seems like a hackjob of bad decisions. Pass the blame Another reason that developers tend to blame the previous developer is because it’s easy. The previous developer no longer has to justify his actions and isn’t there to defend himself. So blaming him is super easy. If a developer doesn’t want to work very hard or solve a particular problem, it’s far easier to blame something inherent in the system rather than laziness (or incomptence). When the boss asks “what’s the timeline on the [whatever],” it’s easy and convenient to say “well, normally it would only take 2 weeks, but since we’re dealing with an older version of [some library], it’ll probably take a month.” It may be true that the older version will take more time, but it also may be true that you, the developer, just don’t feel like working very hard this month. Justification You hired this new developer for a reason. After a series of interviews, some coding tests and whatnot, you finally hired this person. Now, this person has to justify that they’re worthwhile. Developers tend to think that a great way to do this is by making BIG changes early on. Implementing all sorts of processes that don’t need to be implemented and introducing all sorts of tools that no one else on the team has heard of. I’ve seen countless permutations of this behavior, where a developer will come around and say how bad using Pivotal is and that we now need to use JIRA or they can’t believe we’re still using Subversion and how we should move to Git. It justifies the knowledge that we have and hopefully impresses you, oh glorious boss. End it I think it’s a bad practice to simply blame the previous developer or team for something. Give them the benefit of the doubt and assume that they made the best decisions they could under the constraints they had. They didn’t have the knowledge of the fully baked system. In the short term, it may impress the overlords that brought you into the organization, but in the long run, it hurts us all. We’ve all been that developer that’s been blamed for countless problems after we leave — it doesn’t feel very good to know that it’s happening to you, so why do it to others? Take the moral high ground. Even if it is the previous guy’s fault, don’t frame it like that. Be a hero in the long run by being a solid team player that makes good judgement calls whenever you can. Don’t be the short-term hero that throws people under the bus. You’ll probably get away with it, but we (the developer community) won’t like you very much if you do. Now, granted, there are certain cases where the previous developer was a truly terrible developer. In those cases, make the stakeholders aware of everything all at once, rather than as a convenient excuse for you to use whenever you either don’t want to do something or can’t.

Attack of the programming languages and frameworks. — I can’t make a decision on what to learn

Rarely does a week pass when I’m not asked if I've seen some new JavaScript library or framework. Actually, some of them are new and some of them have been around for a while. A friend will tell me he has just completed a project using a particular technology stack. Then, I hate to admit I immediately go look it up and start thinking “I wonder if I should be using that too”. After this, the hunt starts for YouTube video tutorials and a few articles confirming that this is in-fact what I should be doing. I’m in search of confirmation that everything else I've been using sucks and this is the one technology which is better than the rest. What’s wrong with this? Its exhausting! It’s an exercise in tiresome repetition and a great way to not learn anything well. Most developers I know enjoy their work. They may not like their current project, but in general they like what they do. Despite whether they went to school to study computer science or got their entire education from Stack Overflow, the good ones will spend time outside of work improving their skills and trying to stay current with technology trends. But how do you choose what to learn when there is an endless amount of technology options out there? How do you stay current when you work a full-time job and live in one language or framework all day everyday? Here are a few suggestions I would like to make to help put your mind at ease. Don’t worry about what you don't know. There is a lot you don’t know, and by the time you learn something you will discover 3 other things you don’t know. Technology never stops moving . Do not torture yourself by worrying about it. Every developer gets the same 24 hours in a day as you. I used to think I was behind everyone else until I realized this obvious fact. Technology can move as fast as it wants, but individuals only have so much time available. There are not legions of developers out there learning day and night, leaving you behind. Logic is logic. If you are coding, regardless of language or framework you have the training to pick up another technology when time permits. All languages use loops, variables, arrays, functions…etc. You just have to learn new syntax and ways of doing things. “But you still haven’t told me how I choose what to learn!” I've narrowed this question down to three sub questions I think you should be asking yourself. What does my employer want me to learn? Ask yourself what you need to learn to move up or around in your current job. This may or may not be the most interesting technology to you but if mobility at your job is important, learning C# when every application your company builds is in PHP will not help your chances. What are people hiring for in the industry? A keyword job search on Cybercoders or any other tech job forum will tell you what people are hiring for in the development world. You can easily see areas that are in high demand and get an idea of where trends are headed. What do you have a personal interest in? Hopefully you are one of the developers that I mentioned above. You like coding and you are going to have something you want to learn regardless of the previous points. Whatever it is, start building something with it now. Your personal satisfaction is what drove you to study and its important to maintain that. In closing I would like to say “be knowledgeable”. I love to read articles on programming and web development. I follow a few awesome blogs and take the occasional tutorial. This is mostly just to keep my mind aware of what is available. If a problem surfaces, often I’ll recall something I read in passing that might help me solve it. I think this is the best any developer can do while working and keep his sanity. Try to stay knowledgable and sleep well at night. Tomorrow is another day.