Group items tagged

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.

In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that: - Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; - Have a clean contract with the underlying operating system, offering maximum portability between execution environments; - Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; - Minimize divergence between development and production, enabling continuous deployment for maximum agility; - And can scale up without significant changes to tooling, architecture, or development practices. The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).

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

A few years ago, I took on a freelance project to implement an Internet Explorer component in C++. I was billing a healthy hourly rate on other projects at the time, but this particular client insisted on a fixed price. In a bout of temporary insanity, I made an exception.... Every developer knows that accurate software estimation is not possible even when perfect information is available about project requirements (i.e. practically never).....

podobne nazory na estimate trvania taskov som cez vikend cital aj v tomto clanku https://techcrunch.com/2016/12/11/death-to-jira/ , odhady veru nie su easy

Z toho clanku "death to JIRA" vypichujem: For some reason many companies today seem to be terrified of the prospect of writing more than a couple of paragraphs of clear and simple prose. But a well-written 8-page document can define the nuances of a complicated system far better than a whole cumbersome flotilla of interlinked JIRA tickets. ... Feature planning is about communication. JIRA is fundamentally a terrible way to communicate the requirements of a complex system. Words in a row, if written well, will always be better. A v dost vela veciach suhlasim.

uplne suhlasim, osobne si tu informaciu skoro nikdy nestihnem precitat a nemam rad, ked mi to rychlo uteka na dalsi polozku

Do the benefits of practices like Feature Branching outweigh the costs of delayed integration and limiting communication?

uryvok z knizky Thinking, Fast and Slow od D. Kahnemana: "The principle of independent judgments (and decorrelated errors) has immediate applications for the conduct of meetings, an activity in which executives in organizations spend a great deal of their working days. A simple rule can help: before an issue is discussed, all members of the committee should be asked to write a very brief summary of their position. This procedure makes good use of the value of the diversity of knowledge and opinion in the group. The standard practice of open discussion gives too much weight to the opinions of those who speak early and assertively, causing others to line up behind them."

Aj vas irituje nemoznost menit commit messages? Zaujimalo ma vzdy preco, ci to ma dobre odovodnenie a dnes som to nahodou nasiel: The message from Linus Torvalds may answer your question: Modify/edit old commit messages Short answer: you can not (if pushed). extract (Linus refers to BitKeeper as BK): Side note, just out of historical interest: in BK you could. And if you're used to it (like I was) it was really quite practical. Co ja viem, podla mna nie az tak rozumne, ved moznost commit-ovat davame tym ktorym verime, ja nevidim take velke riziko v tom, ked commiters mozu menit messages. Stava sa mi, ze si pomylil cislo JIRA issue a uz je neskoro, nic sa s tym neda spravit. Vtedy ma mrzi, ze som clovek :)

mercurial na to ma feature ktora je natolko specialna ze ani nie je v beznom release :), ak som to pochopil spravne je to nieco ako meta-verzionovanie: http://mercurial.selenic.com/wiki/EvolveExtension