people, in “right and proven” way. Got big investment and ready to build millions or billions dollar company. [no] Experienced building a lot of toy projects, enthusiastic learner, wanna build the next toy. [no] Experienced building a lot of toy projects, enthusiastic learner, have a task to create serious app. Your job (or life) is on the line. [yes] Total beginner, come from different background, want to get something quickly developed. [yes] 1. Knowing About Yourself which one? Wednesday, July 8, 15
the app you want to build. [no] You know the app that you gonna build, but realize a lot of validations needed to proof that. [yes] You just want to try new stuff. Any app is ok. [no] which one? Wednesday, July 8, 15
that always have time to help you. His name is Jeffrey Way. [no, use Laravel instead] You have very close friend that always have time to help you. His name is Guido van Rossum or Adrian Holovaty. [no, use Django instead] You have very close friend that always have time to help you. His name is David Heinemeir Hanson. [yes] which one? Wednesday, July 8, 15
hopefully you wont develop your app on your own. May be you need to do something else for the company and leave the app development for other team. You rarely have time and spirit to write good standard and documentation about your code. Wednesday, July 8, 15
business Care-less and backup-less mistake is very expensive. Easy deployment is very very important for rapid development We dont know what we dont know. Wednesday, July 8, 15
the environment of Staging & Production server need to be exactly the same. Make development (Local) server same with the Production server if possible, otherwise need to heavily test on Staging. Always thinking about the drawback when adding Wednesday, July 8, 15
this features/changes. And test this out. Make your system easily be duplicated/replicated, when you need experiment to the new feature or improvement. Vagrant may be good for solving your problem, but not always. You may want simpler thing like RVM and RubyEnv only to manage your env in the beginning. Wednesday, July 8, 15
on-time. Auto-test is like wearing helmet when riding a bike, you still have chance to crash and die. But you cannot not wearing helmet. Actual user testing is deadly important. Period. 8. Do Test Wednesday, July 8, 15
a long process which block another process is bad. It causes bottleneck that affect much on the whole performance of the system. Same goes with the programmer itself. Do mock-up first when serving client side app, so that they can proceed. Wednesday, July 8, 15
the complex software that are very difficult to be caught in auto-test or user-test, but they are obvious when we review the changes of each commits. Always improve the readability of the code and distribute knowledge earlier. There are lots of drawback of code-review itself, so consider your condition as well. Wednesday, July 8, 15
grows. Avoid reset --hard and/or rebase, or everything related to rewriting history. Unless, you really know what you are doing. Make it transparent when you push something to the system, make a notification to your team when you do so. To avoid blocking. Wednesday, July 8, 15
evnpr
haraduka
ohmori_yusuke
jdbedics
bernhardsvt
kscscr
nbkouhou
miki_small_pin
jscottmo
signer
mansuy
cbtlibrary
dougneiner
reverentgeek
bkeepers
chriscoyier
addyosmani
tammyeverts
brad_frost
irinanazarova
morganepeng
matthewcrist
sugarenia
scottboms
