Group items tagged

vysvetlenie preco nie je velmi vhodne, aby office-management a programatori boli v jednej miestnosti a zvonenie telefonov a postarka vyrusovali tych, ktorych naplnou prace je najma programovat: top performers overwhelmingly worked for companies that gave their workers the most privacy, personal space, control over their physical environments, and freedom from interruption. Sixty-two percent of the best performers said that their workspace was acceptably private, compared to only 19 percent of the worst performers

out of 5 dentists agree that multi-threaded programming is hard to get right. At the end of the day, all that the GIL guarantees is that MRI's native C implementations of Ruby methods will be executed atomically (but even this has caveats). ... So the GIL doesn't 'solve' thread-safety issues. ... One way that we work with hard problems is with good abstractions. ... We're seeing more and more abstractions around threads. An approach that's catching on in the Ruby community is the Actor model of concurrency, with the most popular implementation being Celluloid. Celluloid provides a great abstraction that marries concurrency primitives to Ruby's object model. Celluloid can't guarantee that your code will be thread-safe or free from race conditions, but it wraps up best practices. I encourage you give Celluloid a try.

North encourages an agile, content-first, approach to product development and a mobile-first, in-browser, system based approach to design and development.

celkom zmysluplne best practices pri pouzivani gitu, najma je to strucne a zrozumitelne.

pekny zoznam uzitocnych gemov aj so strucnym popisom - vela veci urobil uz niekto pred nami, a tak netreba znovu vynachadzat koleso

Refactor until you feel you are one step behind the solution you want. Avoid your comfort zone. And while you might see extractions that would probably get you to a better design, don't apply them until you see the need two or three different times. Remember that duplication is cheaper than the wrong abstraction. The best refactors will then naturally arise from the repeated inconveniences, instead of from unbacked ideas of what could potentially be better.