- Let There Be Smite (Pippin Barr) — simple diversion for the 4th of July. It won’t be easy for God to save America. (via Pippin’s blog)
- Basel Wear — to answer the question I know was burning on your lips: “what *did* the Swiss wear in 1634?” Impressively detailed pictures from a 1634 book that is now online. One of the reasons I’m in favour of digitizing cultural collections is that we’re more likely to encounter them on the net and so ask questions like “how did people dress in 1634?”, “why did everyone carry keys?”, and “what is a Sexton?”
- databranches: Using git as a Database — it’s important to approach your design for using git as a database from the perspective of automated merging. Get the merging right and the rest will follow. I’ve chosen to use the simplest possible merge, the union merge: When merging parent trees A and B, the result will have all files that are in either A or B, and files present in both will have their lines merged (and possibly reordered or uniqed).
- Joshfire — open source (dual-licensed GPLv2 and commercial) multiplatform development framework built on HTML5.
"Frameworks" entries
Full-stack tensions on the Web
How much do you need to know?
I expected that CSSDevConf would be primarily a show about front-end work, focused on work in clients and specifically in browsers. I kept running into conversations, though, about the challenges of moving between the front and back end, the client and the server side. Some were from developers suddenly told that they had to become “full-stack developers” covering the whole spectrum, while others were from front-end engineers suddenly finding a flood of back-end developers tinkering with the client side of their applications. “Full-stack” isn’t always a cheerful story.
In the early days of the Web, “full-stack” was normal. While there were certainly people who focused on running web servers or designing sites as beautiful as the technology would allow, there were lots of webmasters who knew how to design a site, write HTML, manage a server, and maybe write some CGI code for early applications.
Formal separation of concerns among HTML, CSS, and JavaScript made it easier to share responsibilities among specialists. As the dot-com boom proceeded, specialization accelerated, with dedicated designers, programmers, and sysadmins coming to the work. Perhaps there were too many titles.
Even as the bust set in, specialization remained the trend because Web projects — especially on the server side — had grown far more complicated. They weren’t just a server and a few scripts, but a complete stack, including templates, logic, and usually a database. Whether you preferred the LAMP stack, a Microsoft ASP stack, or perhaps Java servlets and JSP, the server side rapidly became its own complex arena. Intranet development in particular exploded as a way to build server-based applications that could (cheaply) connect data sources to users on multiple platforms. Writing web apps was faster and cheaper than writing desktop apps, with more tolerance for platform variation.
Read more…
Four short links: 4 July 2011
God Games, Digitised History, git Database, and App Framework
Four short links: 7 July 2010
Work Habits, Smartphone Frameworks, Transparency, and Data Geekery
- The Way I Work: Justin Kan of JustinTV (Inc Magazine) — I admit it, I had written Justin off as “that irritating guy who went around with a camera on all the time” but it turns out he’s quite thoughtful about what he does. I try to keep the meetings small, especially when we’re doing product design. If you have eight people in the design meeting, it doesn’t work. Everybody has an opinion. Everyone wants to weigh in on what the font should look like. The end product becomes the average of eight opinions. You don’t get excellent work, just average. (via Hacker News)
- Rhodes — open source cross-platform smartphone app development framework, with offline sync and hosted data storage.
- How Transparency Fails and Works Too (Clay Johnson) — another thoughtful piece reflecting the general awakening that “being transparent” is a verb not a noun: you don’t “achieve transparency”, but rather you have a set of actors, actions, and objects inside and outside government that provide the checks and balances we hope to get from transparency. It’s a complex system, requiring way more than just “release the data and they will come”. [L]et’s not fool ourselves into thinking though that just because a system has real-time, online disclosure that somehow the system will be cleaned up. It won’t. Data makes watchdogging possible, sure, but more data makes watchdogging harder. Plus, for the transparency solution to work, people have to actually care enough to watchdog. Imagine that your city council, facing terrible obesity rates, decided to enact and enforce a mandatory nudity law to improve its public health. Policy wonks got together and decided that in order to get people to lose weight, they’d outlaw clothing. People went outside naked, and sure, it was a little uncomfortable at first, but basically— the fat people stayed fat, and the thin people stayed thin. The town was more comfortable just averting their collective eyes.
- Meta-Optimize — a StackOverflow-like q&a site for data geeks who groove to topics like “unsupervised methods for word polarity detection”. (via Flowing Data)