Esotropiart

Who knew First, Previous, Next and Last paging buttons would present such a challenge? My my my SQL (stuttering) skills are admittedly unpolished, so it takes a while to wrap my head around what should be simple solutions to programming problems. Nevertheless, I find comfort that I'm not the only one. Paging through records seems to be a very common question online. Not so much how to do it, but what is a "better" way to do it. Complications such as joined tables and locating a unique and properly indexed order-by column transform simple situations into brain stumpers. So far I generally enjoy solving these relatively simple puzzles for Esotropiart. I far prefer minor mental wrestling over giving up and using Wordpress. Wordpress has its place, but I want to keep this project lean and simple as it was from the beginning.

The previous iteration of my website (written back in the PHP 4 & 5 days) sorted the tables by unique ID numbers. I refuse to sort this way anymore because ID numbers don't always line up with sequential publishing. It makes a lot more sense to sort by something like a date and time. All my code has been updated throughout the site to reflect this difference in ordering. It took a while to implement because not all my record types had a date field! For example, I had to write queries to logically order and update about 3500 slide records with dates and times that made sense for the albums that contained them. In one case I added over 40 new slides to an old backpacking album. This meant ID numbers for the new slides had a sudden jump from 39 to 3440 since this was my first album ever, and all the slide IDs were used up by subsequent albums. Good thing I am sorting by date instead of IDs now! For new albums I add, it will be easier to pull the dates directly from the photo EXIF meta tags. My old camera didn't even store EXIF dates, so I have no way to figure out when many old photos were shot. Super annoying! Impossible to remember what time of day I was doing stuff 15 years ago. Even the calendar date is hard to figure out in many cases.

The paging logic is further complicated by my desire to minimize code duplication. It's ideal to avoid writing several chunks of code that do almost exactly the same thing. Since my site needs paging for a variety of records with differing database structures, it is not as simple as writing a few lines of code to cover every paging scenario. Some pagers involve joining multiple tables to get the next and previous records, while others are more straightforward.

It can also be tempting to get stuck in the rut of writing perfectly elegant code before making any changes live. Generally speaking this isn't a huge struggle for me because I prefer to see results quickly rather than worry about perfect coding practices. If something is up and running I get the satisfaction of visible results for my efforts. There is always time to refactor it later. Getting caught up in nitty gritty details means never rolling out new functionality, and that makes any project dissatisfying.

The last couple days I have been very unproductive in code writing because I knew the paging functions needed to be fixed, but I didn't feel like bending my mind to do it. I felt like working on easy stuff instead. So I fiddled with more visual, nitty gritty CSS refactoring which comes pretty easily for me. I'm not using any preprocessors like SASS, SCSS, LESS or Stylus because the last time I was writing CSS full time there were no such tools. Since I know how to make stuff work with raw CSS I'll continue to do so.

Sidenote of Futility Frustration Franchise: Am I the only one who HATES that there are a billion programming languages, libraries and frameworks that all achieve exactly the same result to the end user? Information overload in the web development industry is beyond ridiculous these days. I hope there is a revolution someday soon, when people finally awaken to the obvious fact that the sheer number of paradigms and tools grows at a rate that makes development inaccessible. It reminds me of the denomination problem in churches. Instead of taking part and improving the current situation, just split off and clumsily attempt to state "my way is better because it's the way Jesus intended, and all the others are inferior or outdated." All these competing flavors confuse those who wish to join the community of believers or the programming community. Eventually there will be a unique tool for every developer, and collaboration will become impossible. Reminds me of the Tower of Babel situation. All the workers suddenly speak different languages, insisting theirs is the best. So everyone gets frustrated with the building project and finds a new, far off place to live (actually, that sounds kinda good).

Soon everyone will have their favorite programming tool, but their fickle preference will change weekly as new choices to obsess over roll out, and it will be uncool to use the one from last week. Oh, I'm describing the way things are ALREADY. Oops. I was trying to exaggerate, but in this case the hyperbole that exists in the development world is beyond any efforts to satirize. Though discouraged by the state of things, my belief is that the movers and shakers of web development will someday wake up to this absurd over-saturation of "options," and elitist attitudes, and things will somehow simplify. It is comical to me to see "time saving" tools appear, but the irony is that it takes far longer to learn the new tools and change decades worth of code to fit a new paradigm than to continue using what is familiar, stable and backed by millions of users and code contributors. Granted, there are definitely times for rewrites. However, many programmers have an insatiable fascination with the new, above the priority of solving a problem efficiently. Sometimes the best solution is to make simple modifications to existing code. Perhaps not in my lifetime, but eventually a dictator will come to power and wipe out all the stupid choices. Or the economy will simplify, and there won't be enough innovators left to worry about dreaming up new languages all the time. When programmer job resumes are expected to include a list of 300 language proficiencies to get noticed by employers, you know something is messed up in the world. How many do you know? (not even close to an all-inclusive list of technologies, they can't be listed all in one place without crashing the entire internet) I no longer give a rip. I say R.I.P. to them all! Find one that works and just use it.

I have been wanting to write about this topic for a long time, but most people don't agree with me. They welcome the doom of a hundred million new programming tools released every jiffy. They apparently have more brain power than me, and I accept this lesser status gladly. More power to them.

This should be a blog post all by itself, but it's easier to hide/bury it within another. Most programmers are very dogmatic to defend the insane growth of languages, frameworks and tools, so my opinion is shunned akin to heresy if written publicly. Anyone who cannot (or who cares not to) embrace and absorb every new tool is quickly ostracized by the programming community as a lesser being.

In regard to CSS pre-processors I fear losing some of my understanding of true CSS and the ability to debug it when something goes wrong. Everyone knows this happens often, especially in cross-browser compatibility efforts. Eventually the specifications will fill in the gaps and shortcomings that caused the need for preprocessors in the first place. Learning preprocessor techniques would slow me down from production. Anything that involves learning trendy technologies doesn't interest me right now. I want to see results, not endless code revisions. None of those techniques or language choices effect what the user sees or experiences anyway, so they are kind of a waste of time.

Updating old content can be a beast of a chore. My site is old enough to have many links to web resources that have since moved or no longer exist. I decided to leave all my old blog posts and artwork, even though some are very dated. For example, the blog posts I wrote about CSS years ago were fairly cutting edge and on topic when written, but now they sound ancient. Don't really care. I can barely stand to look at my old artwork because it looks ridiculously bad to my eyes. But to remove everything I hate would mean there is no more timeline of progress and no memories to review. These days I neither try to keep up with coding practices nor do I produce artwork. This website is a fun project, and I want it to remain that way. Overthinking it will just produce frustration, and then I'll give up on it again. If that happens, no big deal either. It would mean returning to a less techy hobby like bookbinding. For now I'll approach this web project in a manner that keeps it fun and interesting.

The pagers are working as I envisioned for the blog, album and gallery. They all use at least some common code, which was my general goal. There are a few more pages that still require paging such as the gallery and album tile views, where multiple images show in a grid format.

The logic to page through groups of images is another coding task I have put off. It's perplexing only because I have been researching methods other than the standard SQL LIMIT and OFFSET approach. In reality using those keywords is by far the most straightforward and appropriate method to page through ordered row chunks (and probably what I'll end up doing). Anyone can read a SELECT query with an OFFSET and know in a heartbeat exactly what the code will accomplish, and it just works... every time. The problem is that most pesky blog writers and Stack Overflow answers out there point out that using OFFSET is not an efficient method for paging through database records. In tables with many rows the entire table has to be traversed row at a time until the OFFSET is reached. This means that page 1000 of results will take longer to load than page 1. There are alternatives to OFFSET, but I don't like those I have found so far. They look like garbage queries to me. Maybe I could understand the code today, but later I would look at it and see absolute gibberish. If the intention of a block of code is not easily discerned at a glance, it requires time to figure out what is happening every time it is revisited, and that is both a waste of time and bothersome. My tables have relatively few rows, and they will never grow to include millions. Therefore, this micro-optimization of SQL queries is probably overkill.

It was fun making the cover image for this post. Found a photo of a pager, downloaded a free LCD font, and composed everything in Macromedia Fireworks (yup, MX 2004). I even drew out the little triangle symbols with squares. Fun stuff. In my opinion Fireworks is still heads and shoulders above all other similar apps for putting together simple bitmap compositions. Even the latest Creative Cloud Photoshop sucks in comparison to an old version of Fireworks for this kind of task. Fireworks is far more intuitive with its genius merger of non-destructive vector and pixel-perfect bitmap tools. It's difficult to put into a few words how it differs, but those who have used it for a while know what I mean. Can't beat it for producing smooth, scalable PNG output with an alpha channel for partially transparent web graphics. Yes, all the other apps can do the same thing in a round-about way, but it's just faster and easier in Fireworks.

The next code trick I want to add related to paging is next and previous navigation by swiping horizontally (obviously for images, but why not also for text articles like blog posts?). Obviously this would only apply to mobile and touch devices. It isn't a high priority either, and other feature additions interest me more currently.