John Resig: Write Code Everyday

(John Resig is the creator of jquery)

http://ejohn.org/blog/write-code-every-day/

- Very good blogpost about a strategy to consistently get work done for side-projects
- Suggestion is to - spend a minimum of 30 minutes doing coding everyday
- Maintaining a 'streak' removes the problems that occur when picking-up-where-we-left-off
(This is we what we usually call 'flow' also)

.Net Fiddle

https://dotnetfiddle.net/bfEOHc

How do I “think in AngularJS” if I have a jQuery background?

http://stackoverflow.com/questions/14994391/how-do-i-think-in-angularjs-if-i-have-a-jquery-background

Shortcuts practice

https://www.shortcutfoo.com/

Teamviewer with Sound on Ubuntu

http://askubuntu.com/questions/419605/teamviewer-9-ubuntu-13-10-sound

Interactive Angular tutorial

http://www.learn-angular.org

Dependency Injection related

http://www.jamesshore.com/Blog/Dependency-Injection-Demystified.html

"Dependency injection is really just passing in an instance variable."

Interactive Resources by Language

Interactive Resources by Language - for Java, Ruby, Python, Javascript

Beginner to Advanced 

http://www.learneroo.com/modules/12/nodes/96

How to keep your best programmers & How Developers stop learning

How to keep your best programmers

http://www.daedtech.com/how-to-keep-your-best-programmers

How Developers stop learning: Rise of the Expert-Beginner

http://www.daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner

TDD related - Disadvantages of Test Driven Development

Bold, underline, text-color added by me (to make it easier to ready for myself).
Text content unchanged

http://stackoverflow.com/questions/64333/disadvantages-of-test-driven-development

up vote92down vote

If you want to do "real" TDD (read: test first with the red, green, refactor steps) then you also have to start using mocks/stubs, when you want to test integration points. When you start using mocks, after a while, you will want to start using Dependency Injection (DI) and a Inversion of Control (IoC) container. To do that you need to use interfaces for everything (which have a lot of pitfalls themselves). At the end of the day, you have to write a lot more code, than if you just do it the "plain old way". Instead of just a customer class, you also need to write an interface, a mock class, some IoC configuration and a few tests. And remember that the test code should also be maintained and cared for. Tests should be as readable as everything else and it takes time to write good code. Many developers don't quite understand how to do all these "the right way". But because everybody tells them that TDD is the only true way to develop software, they just try the best they can. It is much harder than one might think. Often projects done with TDD end up with a lot of code that nobody really understands. The unit tests often test the wrong thing, the wrong way. And nobody agrees how a good test should look like, not even the so called gurus. All those tests make it a lot harder to "change" (opposite to refactoring) the behavior of your system and simple changes just becomes too hard and time consuming. If you read the TDD literature, there are always some very good examples, but often in real life applications, you must have a user interface and a database. This is where TDD gets really hard, and most sources don't offer good answers. And if they do, it always involves more abstractions: mock objects, programming to an interface, MVC/MVP patterns etc., which again require a lot of knowledge, and... you have to write even more code. So be careful... if you don't have an enthusiastic team and at least one experienced developer who knows how to write good tests and also knows a few things about good architecture, you really have to think twice before going down the TDD road. share|edit|flag edited Dec 29 '11 at 15:11 community wiki 9 revs, 6 users 69%Thomas Jespersen

5 Using tools like Pex & Moles you can quite easily avoid writing interfaces for every small damn thing. Moles will help you with that tremendously. –  Robert Koritnik Oct 13 '10 at 9:53 6 Seems like a critism of unit testing and object oriented programming, not TDD. –  plmaheu Feb 5 '13 at 16:13

Software Engineer or Software Writer? Is TDD dead?

DHH , creator of Rails, recently wrote a blogpost saying that he is giving up on TDD. 

Big war started i think in twitter, and other sites. 

Then he gave this talk, a few days back in RailsConf (which seems to be an important Rails related conference) - 

Tip: Watch it at double-speed using the Settings in YouTube..since it is a 1hr talk.

There are several interesting points in this talk. Below are the ones that immediately come to my mind, but I will have to watch again, and improve this post:

1. Software Writers - 

Difference between 'computer science' and what typical programmers like me are working on..I think everyone has that in their mind, but he gave a new term to us - 'software writers', instead of 'software engineers', and that we should focus on clarity, readability just like writers of stories, articles do.. 

He used an analogy of piano creators vs piano players:

Computer Scientists/Software Engineers ~= people who make pianos

Software Writers ~= people who play the piano

When put like that, it really shows how different those two are.

2. Patterns are not really helpful
We become better at creating applications by writing applications, reading others' code, and in the process by developing 'an eye' for it. There is no short cut, like learning patterns etc.

3. TDD is not useful in most cases 

TDD is useful when we know exactly know what is needed - this goes in, and this has to come out. 

In cases, where we are figuring out what the app needs to do, it is not that useful, and is in fact harmful to the code (if you stop believing the idea that functions becoming testable is the ultimate goal).

4. Drafts

The first time we write a class or some unit of code that works, should be considered as a Draft (analogous to drafts of emails/articles/stories etc).

Then we should improve upon that Draft.

-----------------------------------------------------------------------------------------------------------------------------------------------------

Response from Kent Beck (it seems he invented TDD) -

https://www.facebook.com/notes/kent-beck/rip-tdd/750840194948847

Below is a comment that seems to suggest where TDD can be useful and where it is not -

Vasileios Mitrousis TDD is a perfect fit for corporate software, when all the requirements have been written down the last two years of discussion. But when working in a dynamic environment where the specs are changing every day it starts to be an overhead. On the other side, when a system is in production, TDD applied on any patches made can make you sleep well at night. I don't believe TDD it's a history, but cannot be applied to everywhere.


https://www.destroyallsoftware.com/screencasts - Unix, Vim etc related screencasts

7 simple steps to implementing a programming language

http://kjetilvalle.com/posts/implement-a-programming-language.html

Google's web fundamentals handbook for multi-device web development

https://developers.google.com/web/fundamentals/

A Crash Course in Modern Hardware

10 Secrets to Becoming a Great Remote Developer

Very good tips for remote-developers like me:

http://x-team.com/2014/05/10-secrets-to-becoming-a-great-remote-developer/

Excerpts from above article:

Contribute trust every day
It all begins with trust. If you only read one thing here, I hope it’s this.

The very definition of a team is a group of individuals who are bound by trust.
Physical teams suffer from physical barriers (such as a floor for each department) which consequently create tribes and ultimately compartmentalize trust.
physical teams are still able to operate even with weakened trust.
Remote teams, however, live and die by their trust. 

Secret 1: Communicate more than you did with your first girlfriend 

And it’s not just about saying “Hello” every day. It’s about:

When you step away from your desk, you let your team know.
When you realize you’re not going to hit a deadline, you let your team know.
When you have some free time, you let your team know you’re there to help.
When you learn about some awesome new framework, you let your team know.
When you see your team falling behind or bad code getting committed, you let your team know.

You will never collaborate with developers more than on a remote dev team. You are forced to collaborate (it’s collaborate or die, really)

Secret 2: Find time for Focus
It’s really important that you cut out 3-hour blocks of time each day to do nothing but focus on the must-finish tasks of the day. It’s easier said than done, but you’ll love the feeling once you get into a rhythm of doing it consistently.

Secret 3: Find your hedgehog 

And so the idea is to do one thing, do it really well, and you will succeed in life, in your career, and in avoiding getting eaten by a fox.
So find your hedgehog in the development world. If it’s Drupal theming, do that. If it’s node.js, do that. If it’s infrastructure, do that. It doesn’t matter what it is, the point is to focus.

Why? Because companies today only need remote developers when they realize they can’t find specialized developers in their geographic location for niche development technologies.
If, on the other hand, you try to be a jack of all trades, someone who knows front-end, back-end, infrastructure, JS, PHP, .NET, everything…you’re less valuable. It’s much easier to find a jack of all trades within your geographic location. Companies that go remote have specific challenges that require a specific skillset that only hedgehogs have.
The best remote teams are filled with hedgehogs.

Secret 7: Have the right attitude

At X-Team, we have a culture of #sleepcanwait, which means our team doesn’t sleep until they’ve said: “Hey team, how can I help?”
It also makes you feel really good to say that line every day. It feels incredibly good helping out your team every day
Remote teams hire almost entirely based on attitude, because contributing trust every day all starts with having the right selfless attitude.

Secret 9: Your word is everything

When you say you’re going to get something done, you need to follow through with that, and if you can’t, then you need to let the whole team know so they can adjust their own timelines.
Remember: The second you aren’t contributing trust to the team, you won’t be on the team very long. 

Secret 10: Be proactive

If you want to know the #1 secret to contributing trust every day, here it is.
The definition of being proactive is quite simple: it means you make things happen before they become problems.
Proactive means bringing in new ideas around workflow to the team. Proactive means always keeping progress moving forward. Proactive means that you are truly ready to be on a remote team because you don’t need someone to babysit you.
Instead, you are proactive; you get up, you get to work, you know what needs to be done, you check in with your teammates often, and you keep things moving.
If you let laziness seep into your work ethic because you have so much flexibility, you will fail.

Nice Quote

By cellfish in a comment in the following blogpost: http://blog.cellfish.se/2014/05/abstracting-vs-isolating-dependencies.html :

"the solution that solves all your problems is not going to be the best solution for all your problems."

iOS tutorial

A colleague pointed me towards this site:
http://www.tutorialspoint.com/ios/ios_quick_guide.htm

Has Ruby tutorial also

A Journey of a software project & developer

Nice blogpost on medium.com -  https://medium.com/p/19784e23163b

Several interesting points like the below:
Excerpt:

"I decided to quit my part time job and work full time on the app with the hope to focus my time on it and get it out sooner. I would later realise this was a bad move and it had the opposite effect. Having the two jobs allowed me to set apart my time and therefore I could set apart my focus on them, giving me much better bursts of productivity. It forced boundaries upon me in terms of how much time I could put into the app each week. Instead, the time I had just ended up becoming one large giant blur and I got bored easily."