Skip to main content

Headaches

Writing computer software sometimes goes a little something like this:
  1. Brainstorm
  2. Believe that writing software is easy
  3. Design
  4. Change the design
  5. Bang your head against the wall
  6. Wish you hadn't banged your head against the wall... ouch...
  7. Change the design... again...
  8. Write some senseless code
  9. Wake up the next morning and delete the senseless code
  10. Write gibberish on a whiteboard
  11. Erase the whiteboard
  12. Realize that your gibberish was actually somewhat important
  13. Finally get a design together
  14. Write some senseless code
  15. COMPLETELY SCRAP THE DESIGN AND THE CRAPPY CODE!
  16. Draft a decent design
  17. Write bad code
  18. Realize the code sucks
  19. Fall asleep on your keyboard
  20. Wake up at 3 AM and realize you did nothing except type 2000 pages of the letter L.
  21. Bang your head against your pillow... ahh... better than the wall.  Commence sleeping.
  22. Hide underground and crank out some code
  23. Attempt to compile code
  24. Add include statements and the semicolons you forgot.  Attempt to compile code... round 2
  25. Begin talking to the compiler.  Say things like, "Oh, quit complaining!", "Shut up!".  Try compiling again.
  26. Ask the compiler questions like, "What the hell is wrong?", "Why have you forsaken me?"
  27. Repeat steps 25 and 26 for many hours
  28. Run the program
  29. Experience a segmentation fault or some unexpected error
  30. Write about your experience on your blog
  31. Find a dark corner and cry

Comments

Popular posts from this blog

Developing a lightweight WebSocket library

Late in 2016, I began development on a lightweight, isomorphic WebSocket library for Node.js called ws-wrapper .  Today, this library is stable and has been successfully used in many production apps. Why?  What about socket.io ?  In my opinion, socket.io and its dependencies are way too heavy .  Now that the year is 2018, this couldn't be more true.  Modern browsers have native WebSocket support meaning that all of the transports built into the socket.io project are just dead weight.  On the other hand, ws-wrapper and its dependencies weigh about 3 KB when minified and gzipped.  Similarly, ws-wrapper consists of about 500 lines of code; whereas, socket.io consists of thousands of lines of code.  As Dijkstra once famously said: "Simplicity is prerequisite for reliability." ws-wrapper also provides a few more features out of the box.  The API exposes a two-way, Promise-based request/response interface.  That is, clients can request dat...

Wedding Prediction - October, 2013

Carla and I are planning on getting married sometime in October next year.  We need to pick a date, and that decision may  involve some science and mathematics.  :) For example, we want the weather to be nice.  To be more precise, we'd like the high temperature for the wedding day to be between 60 and 80 degrees Fahrenheit.  Obviously, we have both lived in Ohio our entire lives, and we have a pretty good idea of what the weather will be like.  We both hypothesised that October was a "hit or miss" sort of month; it could be cold, or it could be nice. But, for me, a simple hypothesis was not enough; I really wanted to know the probabilities of decent weather based on historical weather data.  Many websites on the Internet (i.e. almanac.com) charge you to review historical weather data, but Carla and I discovered a cool page on cleveland.com that provided exactly what we wanted.  I loaded the historical temperature data from 1903 to 2011 f...

Node.JS + MySQL + Transactions

If you're like me, then you are probably building web applications using Node.JS and MySQL (and maybe Redis, too).  If so, you're probably going to need transactions, and you've probably already noticed that the current version of node-mysql doesn't support transactions yet.  :( But that's OK because I have a solution for you.  Check out node-mysql-queues on github .  This project provides pretty good support for MySQL transactions with a fairly simple API.  There are a couple of things to remember, though.  For one, Node.JS is very "callback-centric," so when executing a series of queries, you would normally chain the queries together with a series of callbacks.  node-mysql sort of changes this model, by allowing you to place queries on a queue to be executed in order.  If you only care about doing something when all of your queries are done, you can simply put your callback in the final query.  node-mysql-queues allows you to do the same...