├── CONTRIBUTING.md ├── LICENSE.txt ├── README.md ├── The-Elite-Startup-Checklist.md ├── database.md ├── deployment.md ├── ethics.md ├── general.md ├── javascript.md ├── python.md ├── source-control.md ├── startup.md └── ui-ux.md /CONTRIBUTING.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dhilipsiva/best-practices/85644fa7c9d09eea2f4bc27768a80b0a4ee9c01c/CONTRIBUTING.md -------------------------------------------------------------------------------- /LICENSE.txt: -------------------------------------------------------------------------------- 1 | The MIT License (MIT) 2 | 3 | Copyright (c) 2014 dhilipsiva 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy of 6 | this software and associated documentation files (the "Software"), to deal in 7 | the Software without restriction, including without limitation the rights to 8 | use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of 9 | the Software, and to permit persons to whom the Software is furnished to do so, 10 | subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS 17 | FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR 18 | COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER 19 | IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 20 | CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 21 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | best-practices 2 | ============== 3 | 4 | A collection of best practices that we have learnt so far. 5 | -------------------------------------------------------------------------------- /The-Elite-Startup-Checklist.md: -------------------------------------------------------------------------------- 1 | # The Elite Startup Checklist 2 | 3 | As I was reading through [The Joel Test: 12 Steps to Better Code](http://www.joelonsoftware.com/articles/fog0000000043.html), an epic post by [Joel Spolsky](http://www.joelonsoftware.com/). It was a 13-years-old awesome post. It had a bit of *corporate* touch. So I decided to write a post with *startup* touch, with his original post as a reference. A 2013ish sartup touch. Now beware, I am NOT Joel Spolsky. I mean, I am not as awesome as he is. I am just a kid who is trying to understand stuff. So everything that I am about to say, might be totally wrong. This is just an attempt to share what I know. That said, comments and corrections are welcomed to improve this article. I have put this on my [GitHub Repo](https://github.com/dhilipsiva/best-practices/blob/master/The-Elite-Startup-Checklist.md). Pull requests are welcomed. 4 | 5 | 6 | ## Who is this article for? 7 | 8 | This article is mostly going to be for startups. I ll try my best to keep this post useful for both newbies and experienced alike. I ll start with some basic and obvious things and end up with more advanced stuff. 9 | 10 | 11 | ## The Checklist 12 | 13 | * Do you use a Mac? 14 | * Do you use comman-line? 15 | * Do you use vim/emacs? 16 | * Do you use source control? 17 | * Do you use CoffeeScript and SCSS/LESS? 18 | * Do you use scaffolding tools? 19 | * Can you make a build in one step? 20 | * Do you have auto deploy scripts to production? 21 | * Do you push code to production almost everyday? 22 | * Do you have auto deploy scripts? 23 | * Do you have a bug/issue database? 24 | * Do you fix bugs before writing new code? 25 | * Do you have an up-to-date schedule? 26 | * Do you use the tools that increases productivity? 27 | * Do you have a good documentation? 28 | * Do you automate tests and other stuffs? 29 | * Do you follow DRY principle? 30 | * Do new candidates do math during their interview? 31 | 32 | 33 | ## Do you use a Mac? 34 | 35 | ### Windows 36 | 37 | Okay, before you start thinking, 'Ugh, yet another Apple fanboy!', I want to tell you that this is purly an intellectuall and well-thought opinion. "How?" you ask. Well, I first started out my carrier with windows as primary development platform. While windows has unbeatable and unparellel Developer Tools for microsoft based products, lets face it, It sucks at Open Source development. And if you are a startup, it is highly likely that you are into open source. Not that it is impossible in windows. It is mostly manual and hard to setup. Most of libraries wont compile on windows. So you will have to download developer builds and install them maually, which mainly involves clicking `Next` button (without reading anything in the dialog :P). If you are used to this kind of approach, I know what you are thinking right now. Isnt this supposed to be easy? To those guys, I tell you my friends it is not. I ll explain more about this is "Do you use comman-line section?" So it is really hard to set you Dev-Env up compared to other platforms unless you are working with one of Microsoft's technologies(maybe for HTML, JavaScript or TypeScript too). So stay away from windows if you can. If you are into .Net stuff, then you obviously have no other choice except Windows. 38 | 39 | ### Linux 40 | 41 | So you think you can't afford Mac. Or you dont want to buy another hardware just because you already have a windows mechine. Do not worry. Linux is here to the resque. While I was using windows, I had to setup a ubuntu machine for deployment. I insalled and realized how easy it was setting up server. I was using python. I beleive almost all *nix distributions comes with python. I didnt had to configure any path like I goofed around with window's Environment Variables. I realized how easy it was to setup. Just `sudo apt-get install `. So I had a bunch of Shell scripts handy to set up the environment automatiaclly. So for development, I think Linux is much better than Windows. And as far as a designer is concerned, he cannot run propritary softwares like Adobe's or Corel's softwares which renders it useless for them. 42 | 43 | ### Mac 44 | 45 | "If Linux is free and does much better than Windows, why would I buy an expensive Mac?" you ask. Becasue Mac is much, much better than Linux. No matter how you tweak your Linux, the UX will never be as much sexier as Mac. I am not talking just about the "Eye Candy" stuff. I also mean its usability. You have AppleScript which you can use to automate your Mac. I have a routine work. When I press a shortcut, I want my terminal to be opened with 5 split screens, each window running a specific command like one ssh-ing into production server, another building and running my last dev-server, another openening up specific files to edit and so on. I can do all of this with AppleScripts+Automator instead of me typing-in everything, everytime. This saves me a lot of time. I think that most of the development-related app supports AppleScript. It has an awesome developer ergonomics compared to any other product on planet. And Should I mention about the new eye-popping, jaw-dropping and mind-blowing Retina Display on MacBook Pro? Okay I now know that this is not convincing enough for you to use a mac. Wait untill you finish the "Do you use command-line?" section. (Some personal info: Yes, I am a fan of apple products. But I assure you, My decision to use a Mac is NOT influenced my emotion. It is purly intellectual as I mentioned earlier.) 46 | 47 | 48 | ## Do you use comman-line? 49 | 50 | Skip this section if you are a designer. While it is worth learning, I think it does not bring any serious productivity improvements for a designer as GUI is their only choice. 51 | 52 | If you are used to GUI, I can read your mind-voice as I type this now. Why the @#$% would I use command-line when I have GUI. You might even think that command-line is old school and belongs to ancient times. If you are one of those guys, YOU ARE WRONG!. Consider a simple scenario. 53 | -------------------------------------------------------------------------------- /database.md: -------------------------------------------------------------------------------- 1 | * Normalize! Normalize!! Normalize!!! 2 | * Make use of both GUIDs and Integer IDs. Expose GUIDs to external world to avoid sequential attacks and use integer IDs internally to compare and filter results in a performant manner. 3 | * Do not use ORMs. They slow down the system. 4 | -------------------------------------------------------------------------------- /deployment.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dhilipsiva/best-practices/85644fa7c9d09eea2f4bc27768a80b0a4ee9c01c/deployment.md -------------------------------------------------------------------------------- /ethics.md: -------------------------------------------------------------------------------- 1 | * If you want to succeed as bad as you want to breath, you will. 2 | * If you use any open source projects, give an attribution to them. 3 | * Contribute to their repo or donate something, no matter how small it is. It is these small things that move an open source projects forward. 4 | * Open source your code as much as possible. 5 | * If you are a startup, hire some freshers who are passionate about technology, and guide and mentor them. Turn them into some valuable stuff that a society could use. And make sure he will do the same thing to some other fresher when he is settled. 6 | * Blog about problems you have faced and the approach that you took to solve it. It might help some one else. 7 | 8 | -------------------------------------------------------------------------------- /general.md: -------------------------------------------------------------------------------- 1 | * Modularity! Modularity!! Modularity!!! 2 | * Always make sure that you name the variables appropriately. 3 | 4 | * Follow a general pattern. It should be clear what a function does and returns. stick to the standards. 5 | * Experiment as much as possible before you use some thing in production. 6 | * Open source almost everything as much as possible. 7 | * Composability - Always keep this in your mind. 8 | * Never change a function signature that some one else has written without discussing with your team first. This is the most stupidest thing to do. 9 | * Write kick ass test cases. This will drag you in the beginning, but trust me, this will hold your back in the long run. 10 | * Write as much extensive documentation as possible. 11 | * Build a CI server. Have it test your code each time you commit your code. That way, everyone will immediately know if something is broken. 12 | * Always stick to the standards and general patterns as much as possible. By that way, any new member in the team can figure things on himself without much help from the others. 13 | * If the logic / idea behind the code is not obvious, either write a crystal clear documentation or rewrite the code so it is obvious. 14 | * Remove redundant pieces of code, UI or anything. 15 | * Never update / upgrade / modify a production server before intensive testing. If there are any compelling reasons to update your server, have an Identical staging server, update / upgrade it, run your kick-ass test cases and if everything seems to be right, then you may continue updating your production server. 16 | -------------------------------------------------------------------------------- /javascript.md: -------------------------------------------------------------------------------- 1 | * Make Fewer HTTP Requests 2 | * Use a Content Delivery Network 3 | * Add an Expires Header 4 | * Gzip Components 5 | * Put Stylesheets at the Top 6 | * Put Scripts at the Bottom 7 | * Avoid CSS Expressions 8 | * Make JavaScript and CSS External 9 | * Reduce DNS Lookups 10 | * Minify JavaScript 11 | * Avoid Redirects 12 | * Remove Duplicate Scripts 13 | * Configure ETags 14 | * Make AJAX Cacheable 15 | -------------------------------------------------------------------------------- /python.md: -------------------------------------------------------------------------------- 1 | * Readability! Readability!! Readability!!! 2 | * Break nesting as much as possible 3 | * user "not" operators while comparing to avoid nesting of statements inside if construct 4 | -------------------------------------------------------------------------------- /source-control.md: -------------------------------------------------------------------------------- 1 | # Source Control 2 | 3 | * Prefer Git unless you have any oher strong reason to use somthing else. 4 | * Keep your runnables on root of your repo. 5 | * Have to main branches - prod (for production) and dev (development) branches. 6 | * And other branches as required - hotfix-* and feature-* 7 | * You NEVER commit directly on prod. 8 | * If there are any severe bugs in prod, then you may checkout hotfix-* from prod, fix the issue and merge it back into prod. 9 | * The only activity on prod branch is to pull from a stable dev or a hotfix-*. 10 | * If you want to add a new feature, then you should checkout feature-* from dev, Implement the feature and merge it back to dev. 11 | * The activities on dev should only pulling from feature-* and pulling from prod which has a hotfix-* merge. 12 | * Avoid usage of GUI tools. GUIs are great for code review. But always use git command line for committing and stuff. 13 | * Try to user --no-ff to preserve branching history. 14 | * We almost always write our new code at the end of the file. This will lead to merge conflict if all of us work on same part of file. Instead, try to write new codes other than the end of file. some where it is more appropriate. This will prevent merge conflict to an extent. 15 | * It is always a good idea to have release notes with a diff of codes. Great for reviews. 16 | * Merge vs. Rebase: Use merge when you want to preserve the branching tree. Using merge will result in a additional merge commit. Use rebase if you dont need preserve the branching tree and avoid the additional merge commit. 17 | * Never commit any external libraries that can be downloaded elsewhere. Possible alternatives are package managers, git sub-modules or Makefiles. 18 | -------------------------------------------------------------------------------- /startup.md: -------------------------------------------------------------------------------- 1 | * Go live! Go live!!! Go live!!! 2 | * Get out as soon as possible. 3 | * Build a very minimal viable product and go out as soon as possible. You never know what users want. This will give an opportunity to learn and build more. 4 | -------------------------------------------------------------------------------- /ui-ux.md: -------------------------------------------------------------------------------- 1 | * Perfection! perfection!! perfection!!! 2 | * After all, this is the part which users will be seeing. 3 | * DO NOT make the user remember anything. 4 | * Everything should be intuitive. 5 | * Users should accomplish their tasks with as much lesser efforts as possible. 6 | * Keep the interface as much simple as possible. 7 | * Everything should be obvious. 8 | --------------------------------------------------------------------------------