Żeby pomóc innym, postanowiłem podpozycjonować trochę źródłowy artykuł.

Najważniejsza dla mnie informacja – dobre kolory do użycia w diagramach:

$ wget \
     --recursive \
     --no-clobber \
     --page-requisites \
     --html-extension \
     --convert-links \
     --restrict-file-names=windows \
     --domains website.org \
     --no-parent \
     www.website.org/tutorials/html/

Rzecz polega na tym, że normalne instrukcje break i continue, jeżeli odpalone są w zagnieżdżonych pętlach, działają tylko na tą najbardziej wewnętrzną. Moim dotychczasowym tradycyjnym podejściem pozwalającym na przeprowadzenie break’a na pętli zewnętrznej było coś takiego:

Można jednak nadać etykietę pętli zewnętrznej i w ten sposób przeprowadzać wyskakiwanie z dowolnego poziomu zagnieżdżenia pętli (jednak możemy przeprowadzać te skoki tylko wewnątrz pętli, której nadaliśmy etykietę i w pętlach w niej zagnieżdżonych). Powyższy kod z zastosowaniem etykiety mógłby wyglądać następująco:

A poniżej przykład zastosowania instrukcji continue bez etykiety:

Oraz z etykietą:

Pomyślnych kodów! :)

Ruby 1.9.2 + Rails 3 installation in Ubuntu

This is one of the key benefits to building web-based software instead of traditional desktop based software. Desktop software makers such as Adobe, Intuit, and Microsoft need to sell you new versions every year. And since they can’t just sell you the same version, they have to justify the expense by adding new features. That’s where the bloat begins.

With web-based software based on the subscription model, people pay a monthly fee to use the service. You don’t need to keep upselling them by adding more and more and more, you just need to provide an ongoing valuable service.

“Because something is happening here / But you don’t know what it is / Do you, Mister Jones?” - Bob Dylan

A lot of web sites & applications make you feel a bit like Mr. Jones.

That’s why we’ve pioneered the Yellow Fade Technique (YFT) in Basecamp. It’s a nifty way to subtly spotlight a recently changed area on a page.

Interface First

Design the interface before you start programming

Too many apps start with a program-first mentality. That’s a bad idea. Programming is the heaviest component of building an app, meaning it’s the most expensive and hardest to change. Instead, start by designing first.

Three State Solution

For each screen, you need to consider three possible states:

• Regular
  (…)
• Blank
  (…)
• Error
  (…)

Most of the time you spend is wasted on things that just don’t matter. If you can cut out the work and thinking that just don’t matter, you’ll achieve productivity you’ve never imagined.

Commercial Alignment

I have often heard it said that an iterative or agile approach isn’t feasible because of the constraints imposed upon a project by delivery contracts. It’s true that this is a common issue for software delivery organisations, but these constraints have typically come about from a breakdown of trust between the delivery team and its customer, typically resulting in a scenario such as:

The customer has little confidence in the delivery team and demands that they provide a fixed-price for the delivery of the solution. In reaction to this fixed-price constraint, the delivery team requests that the customer defines everything they need in detail before a price will be given. The customer, knowing that this is their one chance to specify what they want or risk severe change control later on, provides the details of everything they might ever want. The delivery team ties the customer to this specification, unless they pay extra to change it, resulting in a solution that provides functions that are either never used or no-longer need.

This classic waterfall scenario is typically driven by an old-school procurement mindset that wants to know exactly what they are going to get for their money, even if the business can’t say what it is that they will actually need.