Charlton Wilbur

I've been using object oriented languages and object oriented programming techniques for just about my entire career. I've only come to use Ruby in the past few years, but it feels like I was preparing for it for decades. My first experience with Ruby was actually team-teaching a unit in it as part of a General Assembly web development bootcamp. The other two teachers were expert in Ruby, and so for that unit I took a supporting role as a tutor and classroom assistant. The students were under no illusions that I knew it all ahead of time -- which some of them said they found quite refreshing! -- and I also got to model how an engineer uses reference documentation, simply by speaking my thought process out loud while I scanned the rubydocs in Dash. Since then, I've used Ruby for just about all the projects I once would have used Perl for. You can start out writing clean, well-architected code (and you should, if you can), but Ruby also lends itself well to experimental programming followed by incremental refinement: you can write the first draft of the code as a stream-of-consciousness mess, then break it out into functions once you see the patterns forming, then decompose the data into a set of objects, turning the functions into methods, and covering the whole thing with unit and functional tests.

I've been using Javascript since before the ramifications of the XMLHTTPRequest function were understood and dubbed AJAX. I've used Prototype.JS to add simple interactivity and form validation; I've used jQuery to build single-page apps; I've used Node.js and a plethora of modules to build highly performant asynchronous application servers. I've taught a software bootcamp class how to use the MEAN stack. I'm well up to speed on the changes in ES6/ES2016 and their ramifications, and I've been playing with some of the Javascript-like languages that compile to Javascript, such as CoffeeScript and TypeScript.

I'm not a web designer -- if your page isn't pretty I'll probably agree that it can use improvement but I won't have the first idea where to start. (Well, that's not entirely true. I'd point you at Bootstrap, and if that design language works for your site and your tastes, we'd be off and running.) But if you know what you want it to look like, and you want it to be efficient -- small page weight, usable on different devices and in multiple browsers, responsive, and easy to maintain -- that I can help you with. In spades.

I cut my teeth on C in an academic environment where Unix and C were the common reference points and manual memory management with malloc() and free() were considered essential skills. Nowadays C is rather an Elder Tongue, spoken only by dragons, wizards, and the divinely touched. But if you're wiling to work at C's level, there is nothing more performant, and I can help you with the pronunciation of your incantation.

I've been writing web applications backed by relational databases for over 20 years now; I'm only claiming 15 years, though, because it took me a while to get good at it. I have worked on small to medium applications (with data sets ranging in size up to a couple hundred gigabytes), and I have worked with architectures where the programmers were expected to write SQL pretty much directly, with minimal abstraction between the business logic application code and the database, and with architectures that had object-relational mappers or persistence layers between the business logic application code and the database. If you're working with highly database-specific optimizations and performance tunings, I probably can't help you much, since I'm not primarily a database administrator and I've never chosen just one database to specialize in; but for everything up to that, I can help you get your head around the oddities of SQL and the relational model, I can help you figure out what the database needs to do and how it should do it, and I can help you track down the cause of the really weird errors that seem to happen whenever databases are involved.

I started writing Perl in 1993, when it was a useful language for system administration, before the Web exploded and made Perl the glue that held it all together. But I came from an academic computer science background where everything was expected to be tidy and neat. So I learned to write clear, readable Perl -- it *is* possible, and it's not that difficult.