- Code reviews
- Static analysis
- Health monitoring: availability, resilience, etc’.
There are many options to improve your software quality. One of the most effective methods is to do code reviews with other developers.
Code reviews are as much a social interaction as a technical best practice. In a healthy engineering culture (egoless), team members engage their peers to improve the quality of their code and increase their productivity. Developers understand that the time they spend looking at a colleague’s code is repaid when other team members examine their own deliverables. These days, most of the companies (e.g. Facebook, Netflix, Google, Amazon, Uber) are embracing it, so it’s another sign that something is working well here.
Why Ask For A Peer Review?
- The most basic reason is to find bugs.
If you won’t ask for it, you will miss bugs in your code:
a. Accidental errors – typos or mixing variables.
b. Structural errors – dead code, logic or algorithm bugs, performance or architecture concerns. These are often much easier to spot for an external reviewers the see your work from their perspective.
- You preventing from yourself a great way to learn and get better – Committers are motivated by the notion of a viewer who will look over the change request: the committer tends to clean up loose ends, consolidate TODOs, and generally improve the commit.
- Your code is not as clear as you think it is nor its testability and readability.
Code reviews are very important not only for developers but also to product managers, test engineers, designers and others. In many cases, developers will be the first ones to see the benefits. It will allow them to move faster and with higher quality. Continue reading
Some (raw) thoughts on what are the elements that give you a quality and testable code.
It’s not a full list of TODOs but some best practices that should serve you as a good baseline. If you have any suggestions, please feel free to comment.
If we agree that you must have tests in your project – The next good question is what is a good test?
- It’s FAST – The tests should run fast in order to encourage developers to use them constantly during the development process.
- Stable – The test doesn’t break often. You wish to minimize the false-positive ratio as much as you can. This is why you need ‘small’ tests that are encapsulated and give you a clear sign on what is working (or not).
- Easy to read and understand.
- Catches Bugs! When a test fails it’s most probably a bug.
After the first post on Git 101, here is a set of commands you will use after the first 15-20 minutes of working with it. Some are very useful (e.g. stash your work before you can commit it in order to go for a quick coffee when your code is not done) and some are a quite rare (e.g. setting up a git on a remote server). Good luck.
Update & Merge
Creating a branch (and switching to the new branch) in one line
git checkout -b "The new branch name"
- git pull – to update your local repository to the newest commit. It will fetch and merge remote changes.
- git merge – to merge another branch into your active branch (e.g. master).
Remember that in both cases, git tries to auto-merge changes. IF you have conflicts, You are responsible to merge those conflicts manually by editing the files shown by git. After changing, you need to mark them as merged with
- Preview changes before merging them
Creating a stash (think of it as a temporary place, like a clipboard to save changes without marking them deep in history) of changes to allow you to switch branches without committing.
Here are the main steps and the ways to leverage your new ‘hammer’. Continue reading
I was lucky enough to be in the room for their final rehearsal (yep… it was in the same room that I gave my I/O talk). However, I could not focus on preparing, because their stories were so powerful and inspiring. Each and everyone had a story that kept the ‘wow’ effect. If you have time this weekend… you won’t regrat it. Continue reading
In the past few months, I’ve saw many developers that use local storage for ‘big data’ on the client side. Local storage is a powerful API that let developer save key-value data on the browser. However, it’s got some limitation like: synchronize operation that make it less efficient when it’s heavily used. Moreover, it should replace simple cases (e.g. saving the user state) and not in scenarios where you wish to save lots of data and then have the ability to ‘slide and dice’ it base on your needs with effiency. For that, we used to have WebSQL (which as you know is deprecated from 2010) and the new cool kid in town – IndexedDB. Here I will try to give you a short example that will run nicly both on IE10, Firefox (that match the spec) and Chrome (which need to tune a bit the setVersion update to call onupgrade). IE10 will support IndexedDB as well – so it’s great news to web developers in terms of ‘wild’ support for this important API in browsers. I wish we will see soon Safari (specially, on the mobile) match Chrome for android and give us the ability to leverage indexedDB both on Android and iOS.
Ok, as Linus said: “talking is cheap, show me some code”… Let’s go over the example code. In this example we will save todos to keep things simple. Classic, no? In the end of the post, I will also give two other examples of a ‘todo app’ the use indexedDB, WebSQL and jQueryMobile.