Let’s say you wanted to sort the columns of a MySQL table. Your reasons are your own and I’m not here to judge.
Well, if you were so inclined, the following won’t work:
describe users order by field
…and this won’t work either:
show columns from users order by field
No No! You have to do this:
select * from information_schema.columns
where table_schema = 'my_db_name' and table_name ='users'
order by column_name
And now you know 
Happy Coding
My new hiccup with “Comment On The Movies: A Backbone.js tutorial”, has been deciding how to store our comments. At first I was simply going to use localStorage. It’s supported by multiple modern browsers (albeit inconsistently) & gets the job done. The api to use it is also easy to undertand which is good for a tutorial.
Everything was fine…until I saw the localStorage entry on html5please.com. Did you know there was such a heated debate to stop using localStorage and start using IndexDB in tutorials? I certainly didn’t. Suddenly, I was torn! Do I use the simple solution with limitations OR a robust solution that’s not fully supported (I expected more from you, Safari)?
Then it hit me; this is the web. As with any web project, let’s implement the what’s right and provide support for browsers that haven’t made it up to us yet. Therefore, the default storage option in this tutorial will be IndexedDB with a fall back to localStorage.
(Technically, WebSQL is also an option, but it’s support/implementation issues. In addition, it’s spec has been abandoned by the W3C so it’s off the table.)
The tutorial rolls on!
Happy Coding
-a
The scenario: You have a category on a common class – like say, AFNetworking‘s category to make UIImageView load images asynchronously from a URL. The category source lives in a static library that you’re linking into your main project. (You may, as I do, have the library as a subproject of your actual project.) You attempt to call a method on the category, and you get the dreaded "unrecognized selector sent to instance". You know you’re linking the file into the static library correctly, and that you’re linking the static library into your project.
Before you commence wailing and gnashing your teeth, add -all_load to the “Other Linker Flags” build setting in your main project. Worked for me.
Thanks are due to Dave DeLong for answering this SO question, because otherwise I’d have probably spent the rest of the day wailing, gnashing my teeth, and ignorantly trying build options until something worked.
Note that the relevant docs make this feel kind of kludgy – but I need software that works today, you know?
This gallery contains 12 photos.
I got to talk & take pictures with some of my Ruby/Rails heroes while at RailsConf. If you click on a picture, you can hop to a detail page with an option to download the full rez image.
This year was my first RailsConf. For those that don’t know, RailsConf is “THE” Rails conference that brings people in from around the world. It features keynotes & focused talks by the brightest stars in the Rails universe. It’s story time.
I’ve been returning to my source materials on Agile software development/project management methods recently, just to stay fresh. As part of my study, I ran across a blog post (more of a petulant rant, actually) that cites (actually, mentions in passing, with no real justification) the classic Fred Brooks essay No Silver Bullet in support of the assertion that big-A Agile methods cannot possibly be better than other ways of getting software delivered. Besides suffering from the fallacy of appeal to authority (however meritorious Mr. Brooks’s authority in our field might be), it also falls a bit flat to cite NSB in an anti-Scrum screed. To wit:
Incremental development–grow, don’t build, software. I still remember the jolt I felt in 1958 when I first heard a friend talk about building a program, as opposed to writing one. In a flash he broadened my whole view of the software process. The metaphor shift was powerful, and accurate. Today we understand how like other building processes the construction of software is, and we freely use other elements of the metaphor, such as specifications, assembly of components, and scaffolding.
The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be specified accurately in advance, and too complex to be built faultlessly, then we must take a radically different approach.
Let us turn nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and selfrenewing. The secret is that it is grown, not built.
So it must be with our software-systems. Some years ago Harlan Mills proposed that any software system should be grown by incremental development. That is, the system should first be made to run, even if it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it should be fleshed out, with the subprograms in turn being developed–into actions or calls to empty stubs in the level below.
I have seen most dramatic results since I began urging this technique on the project builders in my Software Engineering Laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness. The approach necessitates top-down design, for it is a top-down growing of the software. It allows easy backtracking. It lends itself to early prototypes. Each added function and new provision for more complex data or circumstances grows organically out of what is already there.
The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build.
(The above is, of course, excerpted from Brooks’s essay.)
Iterative development that delivers frequent releases of working software, and uses feedback to determine the direction of growth for the next increment? And a report of empirical (if decidedly anecdotal) support for the notion?
Sounds pretty Agile to me.
(The full essay is available in The Mythical Man-Month: Essays on Software Engineering
Please checkout Part 1 where I explain the philosophy behind Backbone.js
It’s time to build our Backbone.js app, “Comment on the Movies”. This tutorial will, ideally, give you something interesting to build. Take a look at the finished app (so far) on Heroku & feel free to pull it from GitHub. In addition, I’ve updated the code to use Backbone.js 0.5.3, Underscore 1.2.2, Mustache 0.3 & jQuery 1.7.1. Let’s do this! Continue reading
For one of my “coffee projects” (things I work on for about 20-30 minutes each morning to warm my brain up and stay amused), I wrote a genetic algorithm attack on the Traveling Salesman problem. Because I’m a Big Data geek, I parallelized it with Hadoop.
(Note: I actually gave a talk on this topic some time back, having implemented this same concept in Ruby using Hadoop Streaming. That implementation contained a number of flaws, some of which I’m attempting to rectify. Also, it’s not as though I’m the first guy to work this angle. I haven’t perused the latest Hadoop/GA work in the field yet, because I wanted to maximize my first-hand learning at this stage – but I’ll be looking to other sources for inspiration as I develop and generalize this code.)
This was just done for my own edification; I haven’t put enough effort into tuning this software or studying its properties for this to be considered a serious work of research (yet). I’m not a specialist or any kind of expert with genetic algorithms, beyond my recreational reading. That said, I had some success at building a gene representation and evolutionary mechanisms that drove a population of solutions for an NP-hard problem toward (mostly) monotonic improvement.
What follows is a brief description of my approach to the problem, with code attached. If you are an expert with GAs, I’d love to hear your feedback on what I could do better.
I haven’t spent any effort in this post describing the Traveling Salesman problem, genetic algorithms, or Hadoop/MapReduce. (It was plenty long already.) If you’re interested in any of those topics but need to brush up on the basics, check out the preceding links.
More geekery below the fold…
Node Knockout 2011 took place this past weekend. I signed up with the hope of being a “One Man Army” & winning the solo contestant award. I figured that NodeJs was so easy to use and so powerful (seriously, it’s freaking awesome) that it’d be child’s play. I unfortunately bit more than I can chew however.
Jeff Atwood once blogged: “I don’t think it matters how you conduct the postmortem, as long as you do it“. To that end, here’s my post mortem of the app I didn’t finish. Ideally other developers will learn from my successes and mistakes. :)
