Either I missed it entirely, or knew about it and completely forgot, but … CakePHP has an event handling system, complete with events, listeners, priorities and event data support. Awesomeness!
The term management by wandering around (MBWA), also management by walking around, refers to a style of business management which involves managers wandering around, in an unstructured manner, through the workplace(s), at random, to check with employees, or equipment, about the status of ongoing work. The emphasis is on the word wandering as an impromptu movement within a workplace, rather than a plan where employees expect a visit from managers at more systematic, pre-approved or scheduled times. The expected benefit is that a manager, by random sampling of events or employee discussions, is more likely to facilitate improvements to the morale, sense of organisational purpose, productivity and total quality management of the organization, as compared to remaining in a specific office area and waiting for employees, or the delivery of status reports, to arrive there, as events warrant in the workplace.
Who knew that was a thing?
Phabricator is an open source collection of web applications which makes it easier to scale software companies.
For those people who can’t afford GitHub, this should be a pretty good alternative. Developed at Facebook. All you’ll need to do is setup your git repositories.
P.S.: The best product descriptions ever (for parts of the Phabricator).
Surprisingly, a lot of answers have a very weird definition of “elegant”. But still there are quite a few ones that are elegant indeed.
The F5 key is not a build process. It’s a quick and dirty substitute. If that’s how you build your software, I regret that I have to be the one to tell you this, but your project is not based on solid software engineering practices.
A “standard list of metasyntactic variables used in syntax examples” often used in the United States is: foo, bar, baz, qux, quux, corge, grault, garply, waldo, fred, plugh, xyzzy, thud. The word foo occurs in over 330 RFCs and bar occurs in over 290. […]
Due to English being the foundation-language, or lingua franca, of most computer programming languages these variables are also commonly seen even in programs and examples of programs written for other spoken-language audiences.
Every good work of software starts by scratching a developer’s personal itch.
A lot of my work these days is all around web projects, where versions aren’t particularly used. Code is written, tested, and deployed multiple times a day, rather than once in a while. But if you are doing scheduled releases with major and minor changes, backward compatibility and so forth, please consider using Semantic Versioning.
In systems with many dependencies, releasing new package versions can quickly become a nightmare. If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable). Dependency hell is where you are when version lock and/or version promiscuity prevent you from easily and safely moving your project forward.
As a solution to this problem, I propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented. For this system to work, you first need to declare a public API. This may consist of documentation or be enforced by the code itself. Regardless, it is important that this API be clear and precise. Once you identify your public API, you communicate changes to it with specific increments to your version number. Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.