Skip to main content

Moar Dependencies!

I write a lot of code. I go to work and I code. I come home and I code. I code for charities in my freetime. I code for custom electronics when I’m bored. I code video game playing programs when I need a break from, you know, coding.

The thing is, because I code for a living, not everything I write can be open sourced. And a lot of it might have private information in it that I don’t want to publish to the public. I like to give back to the community. I sometimes donate to open source projects. I pay for the software I use. And occasionally, I manage to give away some code to the open source community.

Code is hard

I get it. Believe me. Code is hard to write, and even harder to read. People are afraid of being judged because programmers (and I include myself for sure) are jerks. And worse than a bunch of people saying nasty things about your project is the prospect that no one may ever care to even look at it. Ever.

But I gotta code

I don’t care. I’m going to code anyway, and some of you are too. We have to. We want to make cool toys for our kids. We want to build tools to make our families lives better. We can’t not code. Programming is the future. Everyone will be doing it eventually. It’s just a part of life today.

We’re going to create software because that’s a part of life. We’re going to create new things and recreate old things. There’s software to automate life, and software to create vintage toys. Software powers everything. It’s going to get written. It’s going to break down. Like everything, it’s going to need changing.

But then what?

As a gamer I have a tendency to plan ahead. I try to think about the future so that I can plan my next move in a video game, and make my life better in the future. This mentality extends itself to my code, and so I think about what happens after I’ve written the software. I’m going to want to change it. I’m going to want to maintain it. I’m going to want to share it someday.

That lends itself to building the code to be maintainable and spend time on design and architecture. I build servers to run my code long-term. And naturally, I use source control.

But source control’s not everything. You need redundancy!

Use Github

So I use Github to keep my code in a second place. I use GoGS locally on one of my servers to keep my software in two places in case my hard drive dies, but when I think the software can be contributed to the community, I put it on Github so that everyone can get to it and contribute if they are interested.

It helps reduce the worry about what other people think if I’m doing it for me and not for others. Since Github is my redundancy server, if it turns out people care, great. If not, who cares? I have a backup!

Use libraries

If you believe anything I’ve said so far, then you understand that the amount of code in the world is only going to increase in time. And much of it is the same. New languages are just a bunch of code written in one of the existing languages with a new syntax. And writing that a thousand times for every device in your house is a lot of work…And then what if it’s broken? Then you have to fix it in 1000 places.

That is not a sustainable way to make the world work in the long term. You need reusable pieces of code that can be updated everywhere with a change in one place. This is what we call a library.

But libraries are bad!

Lots of people say that using libraries is bad because you’re reliant on other people for code.

This is a dumb argument. You can write your own libraries. More than that, you can write your own interfaces to make sure a library is doing what you want it to and doesn’t change and break your stuff. And it’s not like code can change after it’s on the server. The libraries are there for good. Plus, you can manage your libraries! Most companies do.

Libraries are the best

Not just in terms of code quantity, turning thousands of lines of code sometimes into a single reference, but in terms of saving time on architecting and designing good APIs and functionality, libraries save a lot of effort. Libraries consolidate similar tools together in a rational way.

But most libraries are big

Libraries like JQuery and Underscore are what some developers would consider small examples of how big libraries can get. And many times it’s wasteful in more than just hard drive space to have an excessively big library. So we build small tools for ourselves to get by. I find myself building custom pieces of code all the time that I know I’ve build before. The problem is that we are afraid of the number of libraries we reference, so we don’t want to have tiny libraries.

Why not?

I don’t see any reason not to have tiny libraries. This is the modern era. Even in the web, they all get minified into a single library for transit anyway. There’s no extra burden. So I’ve been building a gigantic application for a while and I realized I had a bunch of reusable pieces based on functionality I’ve seen elsewhere. Each piece in this case is a single angular directive. Each library is less than 50 lines of code. Pull in each one as you need it. If you don’t don’t. What do I care? I have a backup. But now I can change things in one place and use these tools elsewhere saving hundreds of lines of manual code per application I build.

So here they are

Without further ado. Here’s 6 angular directives published in the last 2 days after extracting them from my code.

https://github.com/deltreey/angular-esc-key -> http://deltreey.github.io/angular-esc-key/
https://github.com/deltreey/angular-input-digits -> http://deltreey.github.io/angular-input-digits/
https://github.com/deltreey/angular-simple-focus -> http://deltreey.github.io/angular-simple-focus/
https://github.com/deltreey/angular-input-usphone -> http://deltreey.github.io/angular-input-usphone/
https://github.com/deltreey/angular-input-ssn -> http://deltreey.github.io/angular-input-ssn/
https://github.com/deltreey/angular-input-usd -> http://deltreey.github.io/angular-input-usd/

Comments

Popular posts from this blog

Managing Developers is HARD

I've been a software dev for a long time.  I've also been running my own software company for a few years now.  This is important information because of why I do these things.  I am a sofware developer because I love learning.  I slack off when doing a job that bores me, and software development always has something new to experience which keeps me excited and interested.  Why start a software company then?  That puts me in the role of manager rather than developer.  The truth is simple.  I've worked for a lot of companies, and I don't see any of them doing a great job of managing their software development.  That's not to say none of them have done a good job, but no one out there seems to be doing a great job.

How are they different?
A lot of companies get this part right.  Software developers are different from other employees.  The distinction is important in the same way it's important to acknowledge that an insurance agent is different from a construction…

When Is Software Done?

I have some very exciting news.  A piece of software I've been working on for over 2 years is released to the general public!  This is a little exciting if it were software I'd been working on for some big company.  It's very exciting because it's software I have been working on for my company.  That's right!  My company is ready to start selling software and start making money!

I'm not gonna use this blog post to talk about my company and what it does.  You can read about that in our press release.  Instead, I'm going to talk about the software industry and the concept of done.  Because, as with everything, it's more complicated than it seems.

Software is never really done
Actually that's a misnomer.  Software can really be done.  But done is sort of a quantum state--there and not there at the same time.  First and foremost, anyone can understand that software that works is complete.  If the software's purpose is to process a credit card, if th…

How to identify a skilled programmer during an interview

How does one identify a skilled programmer?  No company that has interviewed me could tell the difference between myself and other programmers they'd interview.  The interview process is truly a game of luck in this industry--on both sides.  Both the programmer and the company are basing their actions entirely on luck.

Companies have come up with numerous methods to attempt to discern a good programmer from a bad one.  The best tricks they have include a series of math problems, algorithms, problem solving technique tests, and even obscure programming questions, some without definitive answers.  As an example: Is there an authoritative source of information on the core principles that define object oriented programming?  I've heard everywhere from 3 to 7.  In a field of research about a synthetic concept, an authoritative answer is almost impossible to obtain.

Programmers were then forced to study to the interview.  Careercup is one of my favorite sites for this.  This almost …