More on this book
Community
Kindle Notes & Highlights
by
John Sonmez
Read between
August 24 - August 30, 2018
A stack is a set of technologies, usually including a framework, that are commonly used together to create a full application.
Finally, you take what you learned and you teach it to someone else.
You’ll have a much easier time learning something if you have an immediate application for it—a real reason to learn it.
I’ve already mentioned one good resource for these kinds of problems, but here are some more: Cracking the Coding Interview by Gayle Laakmann McDowell Programming Pearls by Jon Bentley Project Euler Codility Interview Cake TopCoder (check out the practice rooms for the algorithm contests) These problems will be extremely difficult at first, and that is ok. They are supposed to be.
I often encourage beginner developers who are having a difficult time breaking into the industry to consider building a few mobile applications and getting them deployed on one of the mobile app stores. Doing so can help you have the kind of prerequisite proof that you can actually write code and produce a complete working application.
In reality, even though front-end development gets most of the glory, most of the code that exists in the world—arguably the most useful of it—is back-end code that is never seen by the end user.
application. A good back-end developer will know how to utilize various frameworks and libraries, how to integrate them into an application, and how to structure the code and business logic in a way that makes the system easier to maintain. If you like designing the infrastructure of an application, implementing algorithms and logic, and working with data, you’ll probably enjoy working as a back-end developer.
Development teams are building the code multiple times a day and running automated tests and quality checks against the code. Things are no longer as simple as writing the code, building the code and deploying the code. Instead, a whole set of operations and procedures emerged as a way to be as agile as possible and to be able to move code quickly from development to production.
XP relies heavily on the idea of pair programming where two developers sit together and jointly work on all code that is being created.
Instead, the focus really has to change to developing the test cases and test scenarios up front, before any code is even written and to shrink the test process into a smaller iteration, just like we do when we develop software in an Agile way. This just means that we have to chop things up into smaller pieces and have a bit of a tighter feedback loop. Instead of spending a large amount of time upfront creating a testing plan for the project and intricately designing test cases, teams have to run the testing process at the feature level.
TDD usually means using unit tests to drive the creation of the production code being written, but it can be applied at any level.
So, in that respect, we could say the purpose of TDD is to make sure we fully understand what we are implementing before we implement and that we “got it right.” If you sit down to do TDD and you can’t figure out what the test should test, it means you need to go ask more questions.
CVS and Subversion are two examples of centralized source control. Distributed is newer. It’s probably a bit shinier in most people’s eyes and it’s a bit more complicated, but more people are using it.
Git and Mercurial are two examples of distributed source control.
The biggest difference with using distributed source control is that each developer has a full copy of the entire repository on their own machine.
There was a good amount of resistance, but slowly it was overcome as Agile became more popular. Continuous integration wasn’t just a nice dream, but rather a must-have in order to actually have short enough feedback cycles to get work items completed on each iteration.
TeamCity TeamCity is another popular continuous integration server, which is created by the commercial company JetBrains. It has a free version, but it is also a licensed product. So, if you are looking for something with a little more professional support, this is a good option. Many .NET teams use TeamCity for their CI needs.
Clean Code by Robert Martin – I’ve mentioned this book a few times, but it’s one of the best books about writing clean, readable code, and it also includes great information about design and refactoring for maintainability. Code Complete by Steve McConnell – Again, I’ve mentioned this book a few times already, but it’s another great book about writing good, maintainable code. You’ll find this book goes into some of the low-level, structural details of writing good, readable code. Read it. Combined, Clean Code and Code Complete will give you a solid base and understanding of what makes good,
...more
Most great software developers don’t just jump straight into the code and start coding something up.
Don’t come right out and try to convince someone of your ideas on test-driven development (TDD) and why they should be doing it. Instead, do a presentation on TDD. Educate your audience about what TDD is and how it works and how it should be done.

