software

Bret Victor – Inventing on Principle (by CUSEC ) Their principles Elizabeth Cady Stanton — “Women should vote” Larry Tesler — “No person should be trapped in a mode” Doug Engelbart — “Enable mankind to solve solve the world’s urgent problems” (a vision of “knowledge workers” using complex powerful information tools to harness our collective intelligence) Alan Kay — “Amplify human reach and bring new ways of thinking into a faltering civilisation that desperately need it”...

Creators need an immediate connection with what they’re making Bret Victor ’s guiding principle (via his talk Inventing on Principle )

What OO Fails to Do What object oriented programming fails to do is express collaborations between objects. To show you exactly what I mean, let’s take a look at two system operations (two use cases) requiring the same group of objects collaborating with each other. (…) DCI to the Rescue DCI is a paradigm invented by Trygve Reenskaug (the inventor of the MVC pattern) to solve these problems. (via Data Context Interaction: The Evolution of the Object Oriented Paradigm – SitePoint )...

Replacing The User Story With The Job Story We frame every design problem in a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome: When _____ , I want to _____ , so I can _____ . For example: When an important new customer signs up, I want to be notified, so I can start a conversation with them. See also 5 Tips For Writing A Job Story:...

How many bugs and wasted CPU cycles and instances of human frustration (not to mention bad design) have resulted from that one small shortcut about 40 years ago? Keep that in mind next time you want to cut a corner in your code. Rob Pike (via A lesson in shortcuts. Long ago, as the design of the Unix… )

The Twelve-Factor App 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 (…) Codebase Dependencies Config Backing Services Build, release, run Processes Port binding Concurrency Disposability Dev/prod parity Logs Admin processes

Mocks Aren’t Stubs Meszaros uses the term Test Double as the generic term for any kind of pretend object used in place of a real object for testing purposes. The name comes from the notion of a Stunt Double in movies. (…) Meszaros then defined four particular kinds of double: Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists. Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example)....

Due to the interconnected, non-simple structure of ontologies, it’s difficult to give a simple diagram that fully models one. Instead, I’m just going to list the broad categories of classes that you find in an application and simply discuss how they actually interconnect. (via Cocoa with Love: The design of every Mac application ) See also, for a more practical view: What are the Xcode solution organisation best practices and guidelines?...

we-are-star-stuff: If you’re interested in an IT degree and career, coding can be pretty intimidating. From understanding common programming languages to deciphering programming from developing, learning to code is necessary in today’s IT industry. The ability to implement a variety of programming languages can help you decide which coding career path is correct for you. Additionally, comprehending multiple popular programming languages will make you more marketable in the IT industry at large....

97 Things Every Programmer Should Know – Contributions Appearing in the Book Act with Prudence by Seb Rose Apply Functional Programming Principles by Edward Garson Ask “What Would the User Do?” (You Are not the User) by Giles Colborne Automate Your Coding Standard by Filip van Laenen Beauty Is in Simplicity by Jørn Ølmheim Before You Refactor by Rajith Attapattu Beware the Share by Udi Dahan The Boy Scout Rule by Uncle Bob Check Your Code First before Looking to Blame Others by Allan Kelly Choose Your Tools with Care by Giovanni Asproni Code in the Language of the Domain by Dan North Code Is Design by Ryan Brush Code Layout Matters by Steve Freeman Code Reviews by Mattias Karlsson Coding with Reason by Yechiel Kimchi A Comment on Comments by Cal Evans Comment Only What the Code Cannot Say by Kevlin Henney Continuous Learning by Clint Shank Convenience Is not an -ility by Gregor Hohpe Deploy Early and Often by Steve Berczuk Distinguish Business Exceptions from Technical by Dan Bergh Johnsson Do Lots of Deliberate Practice by Jon Jagger Domain-Specific Languages by Michael Hunger Don’t Be Afraid to Break Things by Mike Lewis Don’t Be Cute with Your Test Data by Rod Begbie Don’t Ignore that Error!...