krow
May 17th, 2005 Filed Under ideas, portfolio, projects, software
krow: a distributed software development engine
build custom software from loose specifications, using a large pool of developers and a market to determine priority and compensation. Abstract:
Software developers, potentially geographically-scattered, execute abstract project visions, earning and circulating virtual currency (hereafter ‘krowmids’) which translates into respect, ownership, and real money for successful projects.
The project owner specifies their vision, naming problems to be solved and designing tests which will pass when the system realizes the owner’s vision. Trusted developers enumerate use cases, clarify tests, architect solutions, and segment the project into subprojects, which become concrete [probably automated] tests and tasks to be implemented by those same developers. Developers, customers, and investors pledge krowmids to their favorite projects and subprojects; the implementor earns those pledged krowmids, less any krowmids they pledge to delegated tasks.
Earned krowmids result directly in project ownership, which translates semiannually into more krowmids as those projects are licensed and used by both internal and external customers. Project owners set the prices of libraries and applications, though a mechanism for determining alternative payment structures would be beneficial. External modules may be used by krow projects, contagiously incorporating them into the system.
Senior developers train junior developers in technical skills, project management, and specific projects, granting incremental authority [with a competition-derived belt system] to decide implementation details. Developers strive to earn quantifiable respect and honor from the system and their peers, concurrent with economic sustenance.
krow manages the project database, developer and customer interfaces, project and developer accounts, source control, and test sandboxes. For these services, krow taxes the exchange of krowmids to dollars and vice versa. Transactions on internal markets should remain frictionless.
Thus project owners provide developers with tangible incentive to organize and realize their vision. Developers enjoy merit- and result- based compensation in a relatively stable system, contributing to a wide variety of projects. Investors and customers enjoy finer control over project and feature priorities, while the system enjoys converting the desires of investors, customers, and developers alike into an efficient market for technical labor.
Stumble it!written communication: capitalization
May 13th, 2005 Filed Under random
By default we use lowercase characters, and the uppercase characters function as occasional annotations, indicating emphasis, respect, or uniqueness. Many languages capitalize the first character of the first word of a sentence, serving as a redundant synchronization marker. But the idea is fundamentally the same in all cases: this Character deserves a bit more attention.
Of Course, Using CapItal LeTTeRs too FreQuently ThRows Off THe iNTeRPReTation, resulting in a Subconscious Erraticism Alert, a Mental State somewhere between Confusion and Depression. In electronic media, lamers will use this technique intentionally in an effort to become eLiTe, or even capitalize particular single characters to represent full words, as in ‘RU gay’ which expands as a rather rude query of sexual preference. in english, using lowercase letters exclusively and deliberately ignoring traditional synchronization points, disturbs some people, indicating laziness or potential disrespect. USING UPPERCASE CHARACTERS EXCLUSIVELY INDICATES SHOUTING, IGNORANCE, MECHANICAL FAILURE, OR SOME OLD V60 TELETYPE STOP
compiler-detected race conditions
May 11th, 2005 Filed Under projects
Many moons ago, I sent Andrei Alexandrescu some improvements to his Volatile Correctness–How to Have Your Compiler Detect Race Conditions for You concept. Ultimately, Andrei decided not to teach this technique, as overloading the ‘volatile’ keyword is confusing to developers. For posterity, however, this is what I wrote to him, including the source in an attached tarball:
lockptr.h:a small rewrite of your LockingPtr class, using lock and unlock functions as template parameters; locks.h: my extensions, including RWLock encapsulating pthreads’ functionality, a ReadWriteLockable<> template to inherit lockable classes from, and a Lockable<> template to wrap existing single-threaded classes. I left in my comments that summarize usage and provide some simple examples. locks.cpp: pthreads initializers that for some reason don’t exist in the linux pthreads libs. test.cpp/Makefile: a simple test that repeatedly sums and shuffles a vector<int> in multiple threads and with different locking strategies, reporting execution time for each. On my system, the first two testing strategies fail (displayed sum != expectedSum) as expected, since neither of them do any locking (Test2 uses a Lockable<vector<int> > demonstrating that T and Lockable<T> can be used almost identically). Test3 uses writelocks for everything, and Test4 uses readlocks for summation; both run slower, but provide correct results, and Test4 executes about 15% faster than Test3.
To me, this seems like only a modest performance improvement, since the tests sum elements 100 times for every 1 shuffle. Is the pthreads’ implementation of rwlocks among the efficient implementations? I probably just don’t know what amount of improvement to expect from rwlocks as opposed to mutexes.
