defaults write com.apple.dock appswitcher-all-displays -bool true && killall Dock
Every Software Engineer certainly must have to deal with change. Change is a constant in Software Design: adding feature, changing of requirement or bug fixing.
What is a design pattern? In simplest way I can say, it is a general solution for common problems in Software Development. The purpose of design patterns is to help structure your code so it will be flexible and resilient when its changed.
There are 23 common design patterns that are being used by programmers around the world. In this chapter I am going to describe the Observer Pattern.
install PostgreSQL 9 in Mac OSX via Homebrew | |
Mac OS X Snow Leopard | |
System Version: Mac OS X 10.6.5 | |
Kernel Version: Darwin 10.5.0 | |
Install notes for PostgreSQL 9.0.1 install using Homebrew: | |
sh-3.2# brew install postgresql |
interface GameRulesInputBoundary | |
void moveSouth() | |
end | |
interface GameRulesOutputBoundary | |
void moveSouthSucceed() | |
end | |
class GameRules implements GameRulesInputBoundary | |
def init(GameRulesOutputBoundary outputBoundary) |
When you do your first Sonar run on your project, you get a lot of new quality numbers to play with, but no trends. You only have one data set for comparison, the now picture.
Wouldn't it be nice if you could see the current trend of the project without waiting a couple of month for the 'daily/weekly' Sonar runs to fill up the data? Well, you're in luck! And if you're using git as a version system as well, this is your day. :)
In the Sonar Advanced Parameter documentation you will find a System Property called sonar.projectDate. The property let you tell Sonar when in time the running analysis was ran.
By combining this property and what your version system does best, track changes to source, we can now play back the history of the project as far as Sonar is concerned.
This little Bash script illustrates the concept. To spell out what it does in human readable form:
Notes, comments and errata on Robert C. Martin's Clean Architecture
The book has 34 chapters, with a maximum of 22 pages (chapter 14). Even while involved as a programmer in a project, it should be possible to read one chapter per day, so you can finish the book in about 2 months.
Page 15, just before subchapter "The greater value".
For someone with technical leadership responsibilities in a rapidly scaling product company that’s distributed across multiple time zones, what are the top 3 books you think they should read?
- Flow (Donald G. Reinertsen)
- Flow (Mihaly Csikszentmihalyi)
- Flow (Nonaka, Toyama, Hirata)