At Strange Loop 2011 Clojure’s Rich Hickey gave a presentation (video) on programming and simplicity that rankled some feathers and triggered a heated discussion at reddit.
Duncan McGreggor, decided to contact Python’s Guido Van Rossum to interview him about his keynote talk at PyCon US 2012 (video), specifically his thoughts on callbacks.
James Shore’s post in 2006, “Quality With a Name” summarizes clearly what I try and express and practice in my systems design work.
This is something to not only read and bookmark, but print out to remind folks who are building systems what exactly is good software design.
A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance.
If you’re interested how a number systems I’ve helped design have had such long lives and have grown from small teams to support large ecosystems, “Quality With a Name” is a great place to start
Recently he gave a presentation on evolutionary design that is a good watch.
I’m looking forward to seeing his presentation at Philly’s Emerging Technologies Conference.
OOPSLA held an all-star panel (including Dave Thomas and Martin Fowler), earlier this year, on the must-read paper from Fred Brooks (included in the must-read book “Mythical Man-Month”) “No Silver Bullet — Essence and Accidents of Software Engineering”. Read the paper. Then read the panel’s transcript.
WikiWikiWeb: No Silver Bullet
In “Screaming Architecture” Uncle Bob lays out one of the biggest wins by designing to the problem domain, instead of your weapon (ahem.. framework) of choice:
“If you system architecture is all about the use cases, and if you have kept your frameworks at arms-length. Then you should be able to unit-test all those use cases without any of the frameworks in place. You shouldn’t need the web server running in order to run your tests. You shouldn’t need the database connected in order to run your tests. Your business objects should be plain old objects that have no dependencies on frameworks or databases or other complications. Your use case objects should coordinate your business objects. And all of them together should be testable in-situ, without any of the complications of frameworks.
Martin Fowler wrote a piece in 2003 that addresses a subtle anti-pattern – developing your domain model code devoid of behavior. It’s a short, interesting read, that is related to the development of fat controllers in MVCish applications: “AnemicDomainModel”:
“In general, the more behavior you find in the services, the more likely you are to be robbing yourself of the benefits of a domain model. If all your logic is in services, you’ve robbed yourself blind.”
Vimeo: Eyeo Festival: “Ben Fry & Casey Reas – Eyeo Festival 2011”
A short presentation where they give the background and insight into the future of a tool that has empowered artists, programmers, journalists, and story tellers in the same medium.
Apple is far more than the creation of one man. A casual scan of Folklore.org, a site focused on its history, will tell you that.
But so would Steve Jobs.
He’s created a culture at Apple that is going to go on long with out him.
A few reads about Jobs stood out for me today and I’d thought I’d share them here:
WSJ: Steve Jobs’s Best Quotes – as someone said on Twitter, you could avoid reading a few business/programming/design tomes and just absorb these and be better off.
His Stanford University commencement speech: ‘You’ve got to find what you love,’ Jobs says. He ties in his life history as an adopted child of working class parents, into his pursuit of his dream, the failures he encountered, and the lessons that he absorbed that made him stronger. There’s a bit about life, death, perspective and mission. It is worth reading in full. There are reasons it went viral. You can watch it on YouTube as well. But the text is best.
Anil Dash on “What they are ‘protecting’ us from” connecting Jobs liberal, working class background, with his success, and wondering why some are fighting the policies that enabled stories like Job’s to be possible.
You won’t find much Apple fandom here and I’m not going to wax poetic about Apple products, but in a way, for programmers of a certain age like myself, one of the leaders of the personal computing revolution is now walking off his most visible stage and we have much to be thankful for.
So thank you everyone at Apple, Pixar, and NeXT, and thank you Steve Jobs for providing inspiration, and the foundation for so many careers reflecting creativity, communication, and passion.
Heroku adds suport for Java: Heroku for Java.
Take note of how simple a basic Java web app can be. Sure it’s not Sinatra or Flask, but it is still mighty simple.
Folks who claim that ‘Java is dead’ or that it should die, aren’t facing up to where it shines and what it provides. It has a place alongside Python and increasingly JavaScript in my tool belt.
I’m a happy polygot programmer and have used Groovy, and custom DSLs in Java to help speed application development by enabling those who are closest to change, to be able to harness it.
stdout.be talks about what Presentation Systems are and what their responsibilities could be in an environment where the CMS is no longer a single system, but an ecosystem in “The Post-CMS CMS”. It’s a great post, and reminds me of how we’ve defined the role presentation systems play in our solution stack. (via @SeanBlanda)
Sean Blanda, in a related post says, “If all you want is a CMS, you’re doing it wrong”.
Matt Thompson, in a fantastic Poynter piece, “4 ways content management systems are evolving & why it matters to journalists”, specifically calls out how “Journalism is moving from ‘content management systems’ to “content management ecosystems”. Check out the comment thread.
I just took part in a great 3 day training session with Uncle Bob Martin on TDD and healthy software design. One of the tidbits Bob shared was the history behind the Waterfall methodology that some of us older folks strained against until agile and lean methodologies started to get well known. Waterfall originated in a paper by Winston W. Royce, in which he describes the process… as a straw man to tear down! Unfortunately, the poor information design of the paper (it puts the summary tearing down the methodology on later pages instead of right up front) led those who read the nice graphics on leading pages to come away thinking they found the solution to their software engineering process needs.
Watch Glenn Vanderburg’s “Real Software Engineering” talk on Vimeo about this.
Real Software Engineering – Glenn Vanderburg from Engine Yard on Vimeo.