"The basic shape of the clothes hanger hasn’t changed much in over a hundred years: a flattened triangle with a hook. They’re perfectly serviceable for jackets and button-up shirts but fail miserably when it comes to T-shirts and crewneck sweaters, stretching and deforming their collars. Why hasn’t someone redesigned the hanger already?"

'Russell said this is his “I wish I knew when I was younger" list and I think that’s an enriching way to look at it. The more experience you have, the more different types of projects you tackle, the more lessons you’ll be able add to a list like this. So when you read this list, and when you make your own, you are stepping through years of accumulated experience and more than a little frustration, but in each there is a story worth grokking.'

"If you can’t produce concepts quickly, then you’re working at the wrong fidelity. If your wire-framing serves only to deliver a grayscale version of what you’ve already decided you’re building then you’re wasting everyones time."

on updates to JavaScript is this great selection describing the spectrum of tradeoffs when building many things, not just a language, and IMO describes implicitly the tension between the 'too much' and 'too little' abstraction folks: "But then why any language feature at all? Why isn’t assembler good enough for everyone? Or C? Or C++?...Turns out the answer is “human frailty”. Or put a different way, the process of cognition depends on very limited amounts of short-term stack space in our wetware, and computing languages are about making the computer hospitable for the human, not about telling the system what to do. Our tradeoffs in languages would look much different if we could all easily recall 20 or 30 things at a time instead of 5-10. Languages are tools for freeing creative people from registers and stacks and heaps and memory management and all the rest; all the while trying to keep the creative process and the engineering that goes with it grounded enough in the reality that it’s memory words in a Von Neumann architecture to create systems that are practical."

Paul Irish presentation on HTML5/JS tooling and such; not crazy content, but awesome viewer

another PHP hate, this time much slicker but tangential: "Millions of websites are built with PHP, because it works and it's cheap to run, but PHP is a programming language like scrapple is a meat. Imagine eating two pounds of scrapple every day for the rest of your life — that’s what Facebook does, programming-wise. Which is just to say that Facebook has its own way of doing things that looks very suspect from the outside world — but man, does it work."

"Duck programming also exposes projects to “Naked Risk,” the possibility that bad things will happen without safeguards to prevent it or processes for recovering from disaster. Duck programming can be seductive to development teams because it pushes a lot of project risk away from the project team and onto the shoulders of the users. If something goes drastically wrong, the response from the team will be a shrug and the cryptic notation PEBKAC.3 The system “works as designed,” thus any problem is the fault of the users for misusing it."

"I'm starting to believe that the Managerial class fears programmers the way that Bronze Age nomads feared blacksmiths - programmers wield mystic powers that shape reality, and are best done away with when you are done with them."

I love these "levels" posts and seeing the progression, even if (as most of the time) I'm fairly low myself

some core concepts behind async UIs and how they're implemented in Spine; probably worth getting his book as well

great metaphor to show just how many assumptions are baked into such a seemingly simple task as "hang this picture"

don't read this unless you're somewhere you can have weepy eyes

love reading thoughts behind fundamental decisions like this: "When I was tinkering with this problem nearly eight months ago, I tried a few options like this. It was trivial to come up with a new API to hide some of the complexity, but I was not pleased with the outcome as it meant explicit decision making code thrown all round. In addition, real production-ready code will need to deal with network errors, timeouts, slow servers, HTTP errors, as well as fallback behavior in case of failures. This is the reason ql.io includes a domain-specific language and not a programming language specific-API."

"A healthy product company is, confusingly, one at odds with itself. There is a healthy part which is attempting to normalize and to create predictability, and there needs to be another part that is tasked with building something new that is going to disrupt and eventually destroy that normality."

this is neat if only to see how I've recreated some of these (and ignored others...)

"The screen is a landmine of carefully placed icons that lead to accidental purchases — not to mention the random animated banner ads that are designed to draw attention away from the app itself....if you try to use persuasive design on my young daughter, all bets are off. Your app will be deleted, and we’ll never do business again."

"I am looking for what powerful questions you use in your analysis process so we can create a list ... Here are some examples: 'what is the earliest point you can know whether the system has any value to you?', 'If I turned off the server tomorrow who would be the first person to notice and why?'..."

"Systems sufficiently complex enough to require deep vertical technical specialization risk complexity blindness. Each vertical team knows their component well but nobody understands the interactions of all the components. The two solutions are 1) well-defined and well-documented interfaces between components, be they hardware or software, and 2) and very experienced, highly-skilled engineer(s) on the team focusing on understanding inter-component interaction and overall system operation, especially in fault modes. Assigning this responsibility to a senior manager often isn’t sufficiently effective."

should spur some thoughts about the future of doing anything on the server-side related to views, beyond serving up the resources for them

'...here's a list of docs and other developer resources that myself and others find particularly useful, well-written, and otherwise "beautiful". May they serve to inspire you when writing and designing yours.'

understanding this and following its immediate web could probably suck up a month or two of serious time: "Conklin identifies the following as defining characteristics of wicked problems: 1. The problem is not understood until after the formulation of a solution. 2. Wicked problems have no stopping rule. 3. Solutions to wicked problems are not right or wrong. 4. Every wicked problem is essentially novel and unique. 5. Every solution to a wicked problem is a 'one shot operation.' 6. Wicked problems have no given alternative solutions."

nice overview of the off-the-shelf pieces, the custom pieces, and the general architecture and trade-offs

cute little site that tells you when the last models were released and gives you an idea when the next ones will likely be out

Yes! "You know, we've all been there. We want to make it work with CSS. But sometimes it's just not worth the effort. The hacks and conditional comments ruin our clean markup. And we spend hours trying to make a simple layout work. Occasionally, we have to remind ourselves that we've done enough and it's time to move on."

(2007) "So what was wrong with the design? Quite simply, there was no client in it....There was a technology stack, there were buzzwords, there was a very popular programming language, there were even some quasi-open source components...But there was no client in it. Tract houses are designed for the features that all inexperienced clients want to buy, making owners and tract houses interchangeable."

in-browser wireframing tool, including movement from page-to-page

"Back then, I hadn’t even heard the word “database” before, let alone knew how to use one. So, I needed to get clever....Then it hit me: doing a ls with wildcards was basically instantaneous..."

story/task/test manager a la JIRA, but with some really slick interface features; also github integration

"...to solve complex technical problems does not demand deep technical competence, in fact that gets in the way. There is lots of deep technical competence around: thousands of highly skilled engineers who know messaging backwards and forwards, and who would enjoy working on something as juicy as AMQP....The way to solve complex problems is to make it easy for others to solve them. This is where competent engineers often fail: they understand technology but not people. Complexity is a human issue, and good design is about overcoming human limitations, not technical ones."

this reminds me of Dolores Umbridge...

I love his point around minutes in about taking control of the whiteboard. Completely true.

Nice overview; I like this bit toward the end: "Note what is left out: public / private / static / frozen / const properties and their ilk. Personally, I'm of the view that all of these modifiers are deeply undesirable in a language as dynamic as JavaScript and won't be much used, if added ... but I also think that getters and setters should be deprecated and removed."

deco comics; generally cool, but the Silver Surfer one bothered me for some reason

nice, quick presentation showing that TMTOWTDI (always)

"Tangle is a JavaScript library for creating reactive documents. Your readers can interactively explore possibilities, play with parameters, and see the document update immediately. Tangle is super-simple and easy to learn."

compiles to native app... eventually these will shake out to one or two winners, right?

"Software has become like body language in the way it reveals your inner personality to a patient observer. Your body language always tells the truth, even when you are trying to hide an ugly secret, and it will give you away every time. You simply can’t create likable software if you are a dysfunctional company."

what it means to represent your domain objects as a series of events

"...is a derivative object that retains ornamental design cues to a structure that was necessary in the original. Skeuomorphs may be deliberately employed to make the new look comfortably old and familiar, such as copper cladding on zinc pennies or computer printed postage with circular town name and cancellation lines."

"Bootstrap is a toolkit from Twitter designed to kickstart development of webapps and sites. It includes base CSS and HTML for typography, forms, buttons, tables, grids, navigation, and more."

UX tester who, to his surprise, finds someone in SF who has never used a computer: "When I am convinced that Joe understands how to check his email, I want to show him how he can use his new email address. So, I ask him why he had asked for an email address in the first place. I imagine he’ll say he wants to communicate with friends and relatives.

Joe: “I want discounts at Boudin Bakery.”

Me: “Sorry, what?”

Joe: “I want Boudin discounts, but they keep telling me I need email.”

(Joe takes his Boudin Bakery customer appreciation card out of his wallet and shows it to me)

I’m a little confused, but go ahead and register Joe’s Boudin Bakery card with his new email address. I show him the web summary of all the bread he’s bought lately. “Woah!” says Joe.

"A fauxgo (fake logo) is a symbol or other small design created to represent a fictional company or organization that exists only on film"

"Really, the rule is that a library should drop all its locks before invok­ing an appli­ca­tion call­back. But the sim­plest way to drop all locks is to make the call­back async, thereby defer­ring it until the stack unwinds back to the main loop, or run­ning it on another thread’s stack...This is impor­tant because appli­ca­tions can’t be expected to avoid touch­ing your API inside the call­back. If you hold locks and the app touches your API while you do, the app will dead­lock. (Or if you use recur­sive locks, you’ll have a scary cor­rect­ness prob­lem instead.)"

"And so continues one of the biggest constants in software development: the unerring sense among developers that the level of abstraction they're current working at is exactly the right one for the task at hand. Anything lower-level is seen as barbaric, and anything higher-level is a bloated, slow waste of resources. This remains true even as the overall level of abstraction across the industry marches ever higher."

nice examples, too

having the 'private library' functionality is an interesting twist: "Patternry is a Web design pattern library where you can find solutions to your design problems. It is also a tool for organizations to document, share, and collaborate on design patterns."

well written and reasoned opinion on what java.next should have to be as successful

pretty

from the game, not the old French city

excellent, evenhanded overview of differences (good and bad) between dojo and jquery, coming from a longtime jquery user; one of the main areas she highlights is jquery's lack of code organization

"As more and more application logic moves to the browser, I’m eager to see the JavaScript community rise to the challenge, but instead it feels like the opposite is happening. People with little understanding or appreciation of these questions are taking on projects that demand these questions be answered. The result is a land of fragile code that gets the job done while giving the finger to the next developer; a land of code so tightly coupled, so deeply beholden to the DOM, so blatantly not reusable or extensible or maintainable as to render every subsequent commit a complete crapshoot, as liable to cripple the application as not. The viability of the project is threatened, and so is the reputation of JavaScript."

In addition to this, I've starting thinking of certain core features (or entities) in an application this way "Turtles all the way down is a philosophy where you try to define a ridiculously minimal set of orthogonal axioms and build the language by combining those axioms. At the lowest level it feels like pure math: Combinatory Logic can be built out of three, two, or even one combinator if you are careful. Scheme has five special forms. But with the right abstractions and syntactic sugar on top, you can produce a language with an amazingly diverse feeling to it."

interesting walkthru of how facebook uses data to evaluate and drive features

"Good overview of what "engineering" means and how it's changed, gently moving you toward a conclusion that we're shooting ourselves in the foot by trying to replicate the processes of other engineering disciplines."

some recommendations on protocols

very straightforward example of making a protocol less chatty, in this case SMTP

love this -- such arrogance by the people who say, "Oh, I can code that in a weekend"

write CSS files with variables and expressions, nice

detailed and well explained breakdown of why google's maps seem so much more readable

"COLOURlovers is a creative community where people from around the world create and share colors, palettes and patterns, discuss the latest trends and explore colorful articles..." - can search palettes by hex, though I'm not sure if you have to be exact or just near...
articles...

1UP notifications for user feedback: "That was the easy part. The challenge lies in providing some meaningful and reassuring feedback to the user that the action has been carried out. There are quite a few familiar devices for doing this; the yellow fade technique is probably the most common. Personally, I like the Humanized Messages as devised by Aza Raskin and ported to jQuery by Michael Heilemann."

from Byte Magazine in the 90s

ouch! stamps like: "Let me know when you finish" and "HUH"

I love that animated GIFs have come back; these are a collection of subtle movements from movies

generate as many paragraphs/words of "lorem ipsum"-type stuff as you need.

"This plug-in was inspired by the extJS border-layout, and recreates that functionality as a jQuery plug-in. The UI.Layout plug-in can create any UI look you want - from simple headers or sidebars, to a complex application with toolbars, menus, help-panels, status bars, sub-forms, etc."

Includes "This is not to be confused with one NIEMANN, which describes the force necessary to make a three-year-old put on his shoes and jacket when weʼre already late for kindergarten."

the "I'm worried I left the stove on" is like an OCD honeypot

I don't think we'll be using this, but it was interesting to find it out there: "The XT Framework is a Spring module for developing applications with ''richer domain models and richer user interfaces'', following the Domain Driven Design practices."