Now showing articles in "bootstrap"
Eating my own dog food
Posted 2013-07-10 03:41:48 GMT
You’re a software developer. You write apps for your customers; you don’t write applications for yourself. Users ask you for changes and it frustrates you. You’ve already given them an amazing application, why would they want it changed? You can’t possibly improve on the masterpiece you have already presented them with.
I see this time and time again, and it’s not an uncommon situation. Software developers, when not given a specific spec or set of marching orders, will (to their credit) give users the best they possibly can, and often times become emotionally invested in the work they’ve produced. What should be a simple request becomes a personal insult of the worst kind. Many times, this behavior is unintended: it’s hard to pour a lot of effort into something and not have a sense of pride in the final result. But many programmers are unable to take a step back from the situation and see things from the user’s perspective, because many times software developers don’t get to use the software they create for themselves. They love their work, but not for the same reasons a user (ideally should) love that developer’s work.
I have struggled with this same issue off and on over the course of my career. When I found myself sliding precipitously down this slope again last year, I asked myself how I could best get out of this destructive mindset.
Waste is a pastebin. Pastebins are simple, well-defined problems for programmers, and it gave me a pretty reasonable scope-of-work to run with. And since we were in the market for a pastebin at work, I had the perfect opportunity to write one and eat my own dogfood in the process.
Because I use waste regularly, I quickly became attuned to its flaws. Every problem I find, every bug I squash, every new feature added gives me a personal sense of satisfaction. I am building an app that I love to use, and given my coworkers feedback, that they love to use too. Because I am a user of the app, I also get to see things from the perspective of my clients. Often times, something that sounded great in theory didn’t work out so well in practice. Being a user of my own app, I can quickly spot and fix these issues. I also gain some respect for my company’s users too, who have to deal with similar issues but have no ability to fix them and have to wait for us to address them.
I had to put waste away for a time while other priorities at work and in life took precedence. I dusted it off today and am so excited to work through some of the bugs people have reported and feature requests that have been sitting out there for some time. Does waste have some warts? Definitely. Some of it I chalk up to learning a new set of tools. But every version is better than the one before. It’s quickly nearing the point where I want to throw it out to the world and let them love me or hate me for it.
I encourage every software developer out there to go and scratch an itch. Build something for you, even if there is all sorts of prior art. If nothing else, it will give you a new perspective on the job that you do, a newfound respect for your end users, and if you’re really lucky, will even turn into a successful product that others will want to use. That is the ultimate reward.
In my own case, waste filled a couple of needs for me. We needed a private pastebin at work, and there are some really good ones out there, but they are almost harder to install than it was to write one. And since 2011, I have written waste three separate times: once (as shinyPaste) to learn Catalyst and jQuery UI, a second time (as shinyPaste) in early 2012 to learn Mojolicious, and one last time in the last half of 2012 to learn Dancer and Bootstrap. During this process, I learned to love using Dancer and Bootstrap, and haven’t looked back since.
Building an API
Posted 2013-07-08 14:52:11 GMT
Later this year, for the first time ever, my company has to build an API so third parties can more easily access date stored in our applications. Additionally, we are going to be providing an authentication mechanism for other applications that our clients may write using our API. Invariably, the first time I try something new, I make more than a few mistakes along the way, and I'd rather not make them in this API. So I am going to make these mistakes while designing an API for another product I love :)
IssueTrak, our helpdesk software vendor, has a great API already, but with them going all-in on the development of the new version of their product, they haven't been able to support all the great new features of IssueTrak in their API. So what better opportunity for me to learn something new than to build an API that includes these features?
But building the API isn't enough. I'd like to use this experience to learn some new tools, too. I had originally wanted to use Grape (and learn Ruby), but the sad reality is that if I want to get this done in any reasonable amount of time, I'm going to have to use Perl. So I'm going to change up my usual toolchain a bit. Instead of Dancer, I am going to use the newly-released Dancer 2 (going wild, I tell you!). After some discussion with rjbs, I am going to take a stab (inside joke) at Text::Template instead of TT2. For the help browser, I am going to use PureCSS over my beloved Bootstrap.
I'm hoping at the end of this adventure that I will have learned how to build a sane API that others will have an easy (and enjoyable?) time using, and that I'll have gained some understanding of some new tools that may be useful for future projects. If not that, I'll have had a nice exercise in expanding my horizons, getting out of my usual habits, and finding another way to do things.