Net Minds DevTeam

Nov 01

Petition Your Employer to Close on HaloDay

Seriously, you know you’re going to call in sick anyway, so as tech companies, let’s just agree to close our offices on November 6. So many people called in sick when Halo 3 was released that Urban Dictionary added the definition Halo Day. Corporations feared the wave of suddenly sick employees, and who wants to put their companies through that kind of worry ? Instead, just get them to close! Is there even enough time to vote, play Halo 4 AND work, anyway? Something’s gotta give, and that something is work. After all, Master Chief has to save the universe and you need to help him.

Here at Net Minds we’re already stocked with energy drinks, Cheetos, and pizza rolls in anticipation for some nonstop marathon gaming. Join us. Your employees will thank you.


Oct 22

This Election Day, Being a Teabagger Comes Back in Style! (You know that’s a Halo reference, right?)

This November 6 marks an extremely important day and we all need to do our civic duty. That’s right, we’re talking about the return of Master Chief so you have a duty to play Halo 4… but before you do, you need to vote.

Why do you need to vote first? Well, it’s obvious you won’t take a break from teabagging some noob just to punch a ballot card. You’d probably like to pretend you’re that disciplined, but you’re not.

But that’s okay… that’s why at Net Minds, we’ve made the decision easier. We’re closed on November 6 so that we all have time to vote and play Halo 4.

But we don’t think we should be the only tech company or startup closed that day. Everyone should be closed that day so that employees have time to vote and pretend they are Spartans.

Won’t you join us?

Petition your company to close on #Haloday!


Oct 11

Net Minds Tech Stack (Part 1)

by Alan Baker

The world of application development changes rapidly. If there’s one thing I’ve learned it’s that there’s never just one way to solve a problem.

Take technology and programming: non-programmers don’t usually understand this, but programming has soul. Application design has so many possibilities; even programming simple functions can be done in many ways depending on the personality of the programmer. Just as in art and writing, we transfer our philosophy and personality into the code we write.

Programmers and application designers have the added challenge in that code can do nearly anything; it just comes down to time and money. And making it easier but also harder is the amount of choices we have to write applications, including the massively growing choice in technology.

I want to look at the choices we’ve made at Net Minds and why. I’m breaking this post up into parts so it’s more manageable to read, so for this post, I’m covering the core language we’ve chosen to develop in. Later, I’ll cover our API, database, and front-end.

Just to get it out of the way, we’re a JavaScript shop, from front-end to back-end. This decision was relatively easy.

First, JavaScript is absolutely ubiquitous. JavaScript is the language of the browser, and it controls everything interactive to provide the kind of experience customers expect in a modern web application.  This was important for us because we wanted to design our application around the user experience and we felt that the browser as our platform is a legitimate choice, albeit a controversial one.

And then there’s the huge uptick in developer activity in the JavaScript world – compared to other languages we’ve all used, it’s much more expressive to develop with and a lot of fun… yes, fun.

When you look at the activity on GitHub above, which did surprise us, you really can see the excitement surrounding the language. All this activity shows there are fast cycles of continual improvements and tons of examples of different ways of programming.

Where I get excited in the overall application design, we have less likelihood of investing gobs of time and resources into eventually-abandoned codebases.

JavaScript had everything we needed. Not only that, but all the Net Minds developers know JavaScript very well vs. only two of us who know PHP very well. While PHP has been good to the two of us, the math seemed clear.

This isn’t to say that this is the end all be all for everyone, but for our use case, this logic and our development needs fit perfectly. As we’ve been developing, we are finding that our logic is cleaner; we have a better ability to mix asynchronous and synchronous actions without crazy nested loops and callback hell. So we’re clear, I’m not saying that JavaScript actually solves this particular problem, but we’re better able to see it and manage it.

But most importantly, we’re able to iterate our application design and feature list with far less pain. We’re able to maintain consistent logic and portable code from the front-end to the back-end because we have one unifying language.

For me, this is extremely critical. I think a lot of our user experience and assumptions are really very solid, but like anyone, we’re not perfect and we won’t always be right. But being right all the time isn’t important, instead what is important is to recognize when you’re wrong and quickly iterate.

For our team, JavaScript allows us to do just that. Not bad for a language that was originally written in ten days; not to mention the impressive pace at which improvements to the language are happening. The future just looks extremely bright for JavaScript, especially when you look at the draft proposal for ECMAScript 6.

Well, that’s all for now. Stay tuned for part two when we discuss our front-end, Ember.js.


Sep 05

Say Hello to Drew Purdy!

"He’s what we like to call Man Purdy…"

Drew joins us as our Javascript Spartan Developer. Hmmm… I see a pattern here. With Drew aboard, we have now been able to complete the Triforce of Javascript to ward off Ganondorf, I think he’s a .NET guy.


Aug 30

First official “How Not To…”

Arbiter here. As our beta launch begins to loom ever closer, this seems to be a good time to start revealing more of the inner workings and personalities that comprise the Net Minds DevTeam (codename: Stache 5, as in mustaches. For everyone. Even the ladies). Over the past few months, we’ve learned a lot - what to do, what not to do, best practices, not so best practices, how to properly bag your groceries, etc. Mainly, though, we’ve learned what not to do. So as our first official blog-type post, I’m kicking it off with a How Not To Do Pair Programming.

Pair programming is when two (or more) people get together to well, program. It’s a great format for not only introducing people to new technology but helping them to learn it. Or making them hate it depending on how you go about it. Use-case: 

There are a few more use-cases but these should cover the basics. Until next time… Arbiter out.

Aug 21

How to Ensure You Don't Get Help With a Bugfix

Jul 31

Say Hello to Tyree Pace…

and make her give us a fun title! Tyree, Javascript Developer, joined Net Minds in March 2012. She loves Halo and has pre-called in sick November 6. Yeah, and obviously, as with Maurice, we didn’t have a Tumblr account yet, so we’re announcing it now.

EDIT: Tyree is now the Net Minds Javascript Arbiter!



My Kindle!

Say Hello to Maurice Rickard!

Maurice Rickard on Twitter (@mauricerickard)

Maurice, Developer/Bit Wrangler/Special Ops, joined our team back in May 2012. Since we didn’t have a Tumblr account then, yeah, I know lame, we couldn’t announce anything….


Calling all editors, designers, and marketers! Looking for a new way to get paid? Click me!