Two Weeks Into the New Job: What’s Working and What Isn’t?

This entry is part 4 of 4 in the series Joining Red Hat

Not counting my orientation I’ve now completed two weeks of work in the new job as a Quality Engineer at Red Hat. There’s been adjustment and learning and getting to know a new team and HR paperwork and fun and rough edges.

I think its a good time to take a step back and figure out what’s going well and what isn’t and how to turn some of the later into the former.

So, let’s start with the good. What’s been going well at the new job?

  • The product I’m on the QE team for is built using the back-end and front-end web technologies I’ve been using for a decade in some areas (Django) and at least years in others (React). Without even peering inside this has already given em some insight that’s made the transition and some of testing a lot easier. Familiarity is helpful even when I’m not directly building the product, it turns out.
  • At all levels I’m clearly supported in my transition and see the same support going to other recent additions, so I feel pretty comfortable experimenting and exploring where I feel I need.
  • Respect is going both ways. Even as the New Guy I don’t feel like I can’t speak up to argue against a point. The rest of the team is immediately accepting of my input as if we’d been working together for months. I think that goes both ways, because I definitely need to rely on the assumptions of their knowledge and when I reach out I’m confident of getting what I need.

But, a new job is still a new environment, a new workflow with new expectations, and a differnet technology stack and practice. With all the positives and the remarkably smooth transition there’s still bound to be some rough edges.

  • I’m set in my ways after a decade building the same kind of products with largely the same stacks and teams! The move into a team that uses much  of the same technology also means a move to a team that uses that technology differently. That doesn’t mean wrongly, of course, but I am a developer with strong opinions about the ways I do things. I think there’s more room to push for the cases where I’d like to change something for subjective reasons, but so far I’m still finding the accepted edges around which I can make those pushes.
  • Quality Engineering is a top-down view and I have deeply ingrained experience with a bottom-up view of building software. I’m not yet used to focusing on production and production-like environments rather than light developer environments for my day-to-day work. There’s some overhead involved in essentially a QA role that, as a developer in my previous role, I have really strong urges to strip away. Removing those layers would be a detriment to the whole point of the end-to-end tests we need to do, so I have to fight it.
  • The deep knowledge and established practices of Quality Assurance and Engineering is pretty foreign to me as an explicit pursuit. Sure, I’ve tested my software and I’ve worked with QA professionals. What I lack is a lot of the cultural experience that this niche of the software industry has built up, just like the niches I’ve been a part of in the past. That’s something I can learn from a vast selection of material, but a lot of it will take time to absorb through working with more experienced folks and just gaining my own experience slowly.

Of course, I hope that I can continue to have more of the positive experiences than the negatives experiences. So far, that has absolutely been in the case. I’ve already made good contributions to the work and I’m sure I’m in a positive to do some great work. That’s exciting! I’m not under any illusions that I’m walking in like a rock star. I know there’s an enormous amount I have to learn, but I’m likewise realistic in that I understand my own experience is still bringing a lot to the table.

It feels good to be confident. Is also feels good to have so much to learn.

My Software Job Transition Strategies?

This entry is part 3 of 4 in the series Joining Red Hat

I’ve been spending a good deal of the last two days preparing mentally for starting a whole new challenge as a developer. New things aren’t new to me, but this is different and big enough really call for some Deep Thoughts ™. For one thing, I’ve made a big move from the world of Python web development to totally other Python work and while web development has never been the only thing I do, it has been the only work that paid the bills.

That transition isn’t one that bothers me or daunts me, though. Instead, I’m thinking about transitioning to the scope of the work I’m getting into. For a long time, I juggled multiple clients and client projects every day, so no single project usually took up most of my time. Every developer juggles time through the day, but exactly how that works in each company and on each project varies a lot. I was looking for a place that I could really focus in a way that I haven’t for a long time. I think I found that, but now I have to deal with the consequences.

What exactly happens when a developer experiences a big shift in working scope and all the temporal expectations around the work we do?

One of my concerns making this change is the way I on-board to all the new work when it is something of a shakeup compared to the work I’ve been used to doing. I don’t want my acclimation to get in the way of the first tasks I’m giving or, worse, to get in the way of other people on my team. So that’s the word of the day: acclimation.

I need to focus my first couple days on maximizing my ability to acclimate to new tools, new projects, new workflows, and new teams. Everything is changing all at once and I’m going to have lots of questions and lots of problems I need to reach out to people for, or that will be answered or solved as a natural part of the on-boarding process. If any of that information slips my mind or has to get drilled into me repeatedly before it sticks then I’m taking up more of my time and someone else’s than I need to, so Transition Strategy #1 is that I will Take All The Notes.

 

Notes are only as useful as you can get out of reading them. Every day there’s going to be a running log of the things I learn, the things I try to do, everything I observe. That journal is going to get routinely, through the day, rolled into a living outline of the questions, tasks, and understanding I accumulate over the first few weeks. At any time those notes need to be a snapshot of my brain because it is going to be an overwhelmed brain and it needs all the help it can get.

Of course, those notes are going to be far from perfect. I’m going to make mistakes in them and I’m going to understand things wrong when people explain something new to me, so my notes will reflect mistakes as well as understanding. Transition Strategy #2 is going to be failing as fast as a person, not just a rule for software. I’m going to ask someone early before I waste more time than I should. I’m going to take advantage of the experience and knowledge around me to get up to speed and become valuable as soon as possible. I believe my reaching out as a new team member is a good investment for the team and won’t let things like fear of looking dumb to keep me from getting a helping hand.

With notes and with people I’m going to get a ton of information and I’m going to have a lot of knowledge to sift through. That’s inevitably going to take time no matter how much I try to reduce it, be more efficient, or offset my blundering with careful planning. I’m going to decide that’s okay. It is expected, it’s a normal part of a transition, and I’m not going to get held down further by frustrations that I’m not adjusting fast enough or well enough when I’m really just progressing in a totally expected pace with totally expected problems. Transition Strategy #3 will be patience, both for the time this transition takes and for me to figure it out.

Onward and Forward: I’m at Red Hat now!

This entry is part 1 of 4 in the series Joining Red Hat

I’ve been in development a relatively long time and I like to think I’ve come a long way. My career has included a lot of different kinds of work that I’m proud of and learned so much from. I’ve also spent two-thirds of that time at one great, wonderful place: Caktus Group. The people I’ve worked with have been a privilege and much of the work I’ve done has been so very rewarding.

Nothing lasts forever and I want to continue to grow as a software developer. I’m not going to do that in the same environment at this point in my career or my life. I needed something new! I’ve made the tough decision to leave after nearly eight years.

So, onward and forward to new things! Next week I’m starting a new job at one of the most respected companies in the open source community: Red Hat. I’m sure I’ll bump into a lot of people I know from the years, and I’m going to be getting heavily back to my Python roots in this position so everyone can expect to see me at Python meetups again, probably at PyCon, and actively hacking again on old and new projects on my Github, on the open source work I’ll do at the new gig, and I’ll be certainly doing heavy tech blogging again as I’m finding new and great things to learn every day.

It would be cliche to call this bittersweet, but damn is it accurate.

Interrupting Coders Isn’t So Bad

Here’s a hot take: disrupting coders isn’t all that bad.

Some disruptions are certainly bad but they usually aren’t. The coder community has overblown the impact. A disruption can be a good thing. How harmful disruption might be a symptom of other problems.

There are different kinds of disruptions. They are caused by other coders on your team, managers and other non-coders, or meetings throughout the day.

The easiest example to debunk is a question from a fellow developer. Imagine someone walks over to your desk or they ping you on Slack, because they have “one quick question.” Do you get annoyed at the interruption when you were in the middle of something important? You help out your teammate quickly and get back to work, trying to pick up where you left off. That’s a kind of interruption we complain about frequently, but I’m not convinced this is all that bad.

You are being disrupted but your team, of which you are only one member of the whole unit, is working smoothly. You unstuck another member of your team who may have lost more time without your advice. You can’t consider only your own time. If the disruption does cost you, it is weighed against your teammate.

When a junior developer disrupts you with a question your support of them is important. They can spend more time stuck than you’d spend to help. Consider how much time you’re actually saving by being interrupted if you include others’ time in that equation. This can lead to a long-term boost for the whole team as they learn from you and others.

In either case you should trust your teammates.

The most common disruption complaint is the “hapless manager” walking over to the in-the-zone programmer for a question. Developers think this yanks her out of a productive state of mind that’s hard to get back to. Do five minute interruptions really cost an hour of productivity? Does it take a long time to get back into a state of mind where you’re productive?

There is an often smug animosity towards non-coders who don’t understand what making software is like. They interrupt us, we like to say, because they don’t understand how a programmer’s mind works. This attitude inflates our perspective of what that interruption costs.

But, our managers want us to work well. Any good manager’s job is to support you in your work. We can communicate when real focus is necessary, but don’t be antagonistic about it. Everyone understands context switching, so include this when discussing schedules and allocation. It should be a part of the process to support the focus you need. Like the developers on your team, your manager needs your attention sometimes. Remember to think about the time of the whole team and project. Don’t think only about your own time.

Remember that the actual act of writing code is only a part of our job. Collaborating with our team and coordinating with our clients and company are just as important. Disruptions from outside the technical team are not taking you away from your work. Those interactions are the work, too!

Interruptions can be irritating but they can also do more good than harm in a cooperating team.

And, sometimes an interruption actually helps you.

Those deep states of mind focused on a problem can feel like an important key to cracking a really hard problem. You just need to dig into the depths of the codebase for three hours to figure out how to solve those really thorny bugs, right? Those deep dives can be fraught with false tunnels and misconceptions along the way. An occasional reset can help a lot! A little interruption of your train of thought means you can look again with fresh eyes.

Opportunities in your work day to take a break from a problem and come back to it later are great. It can be good to have something to take you away from your desk. The truth is that “zone” we’re often in can just as likely see us stuck as it can see us through to a solution. Whether it’s taking a break to attend a meeting or juggling a few projects, something to redirect yourself to gives context switches that can be very helpful. Give developers some options for how to spend their time and give them reasons to break up their day.

A specific interruption can be frustrating but they are not inherently costly to a project. Pay attention to the balance, of course. You have to have a team you can trust, both among technical and non-technical members, too.

So, the next time you gripe about being pulled away from coding, think a little closer about it. Are you putting your team ahead of yourself? Are you giving yourself the breaks you need? Good teams give developers time to focus, but good developers give their teams their attention in return.

Respect and Code Reviews

Code Reviews in a development team only function best, or possible at all, when everyone approaches them with respect. That’s something I’ve usually taken for granted because I’ve had the opportunity to work with amazing developers who shine not just in their technical skills but in their interpersonal skills on a team. That isn’t always the case, so I’m going to put into words something that often exists just in assumptions.
You have to respect your code. This is first only because the nature and intent of code reviews are to safeguard the quality of your code, so even having code reviews demonstrates a baseline of respect for that code. But, maybe not everyone on the team has the same level of respect or entered a team with existing review traditions that they aren’t acquainted with.
There can be culture shock when you enter a team that’s really heavy on code reviews, but also if you enter a team or interact with a colleague who doesn’t share that level of respect for the process or the code. This mismatches can lead to conflict, arguments, resentment. They can lead to dwindling code quality and eat at the respect and will the whole team has for adhering to the code review.
Hold fast if a new member joins your team who doesn’t buy into the code review sanctity. They will often take code review feedback personally, and their apparent disregard for your suggestions is easy to take personally, as well. That’s a recipe for bad blood and arguments, so try to defuse it quickly.
This brings us to the next respect you need to have.
You have to respect your teammates. You aren’t a collection of programmers who just happen to be working on your tasks in the same codebase. You don’t function independently within the team but as a unit. Code reviews are one thing we do to guide and enforce that idea.
The respect for your teammates goes both ways during a code review. There is respect from the reviewer to the reviewee, as well as the reviewee to the reviewer.
As a reviewer, your attitude and approach can make or break your colleagues’ respect for the process, the team, and you. There are some easy tips in the feedback you give and especially in how you give it, which can make them easier for both sides.
  • Try to avoid blaming “you” language. Don’t say “You didn’t do this right” when you could say “This would be less likely to break if…”
  • Use “we” language to convey the team ownership of the code. If some code convention wasn’t followed, don’t say “I prefer that you…” or “You incorrectly…”, rather say “We always follow array items with a comma, even the last one.” etc.
  • When using “I” language, use soft phrasing. Don’t say “I need” or “I know”, but “I usually” or “I’ve always found”.
  • Just be respectful and review the code for the team, not against the reviewee.
You have to respect your reviewer. I’ve given most of this advice from the perspective of reviewing code, but this rule is all about having your code reviewed.
The first rule of having your code reviewed is “Don’t take the code review personally”. Your code is not a reflection of you and it is never perfect. Your approaches can be great, but everyone can have valuable feedback. Accept feedback with some empathy and humility.
The second rule of having your code reviewed is “The team reviews your code because the team owns your code.” You do not own your code. Even when you’ve just written it when no one else has touched it yet, even if you put hours of effort and sweat into it. You do not own your code, this bears repeating. So, when your code gets reviewed remember that what eventually ends up in the project has to meet the team’s standards and idiosyncrasies. Often, it is essential that you bend your own preferences. You have to allow the code to work for the whole team, even changing your vision. Our code styles and practice should be in context to the team and project we work in, so don’t be completely tied to one approach, even if it’s your favorite approach.
You have to respect yourself. I’m not to write this without including the respect you need for yourself because the rest of the article was dominated by everyone else. Of course, this can mean a lot of things.
Respect yourself to speak up or push back when feedback you get really is wrong, in your opinion. Make your case strongly, but still keep all the advice above in mind when finally coming to a conclusion.
Respect yourself to be a little dignified responding to code review feedback. Don’t take it personally and look petty. Don’t ignore any bits of the feedback without making a case for why, looking dismissive. Don’t get angry about changing code you really looked and highlight your ego.
Respect yourself enough to look good in your teammates’ eyes at the end of the process so everyone can be happy with what finally goes into the project and shared by the whole team.

A Fond Farewell to the Lost Decades Podcast

How long have I been listening to the Lost Decade Podcast? Three years? Maybe five years? Listening to Geoff and Matt talk about their exploration of game development and the business and life around it has been a part of my every week.

I honestly can’t remember a pair of game developer icons that I more deeply identify with.

Recently, they announced that Lostcast is coming to an end after all these years and the last episode has been published, now. I haven’t brought myself to listen to that final episode. Maybe I’m holding on to the feeling of looking forward to it just a little long.

So, I want to say a deep and heartfelt thank you to both of, Geoff and Matt. The podcast has made me feel like I really am a part of the game development community. If I can identify with two great indie developers as much as I do with the Lost Decade pair, then I can feel much less out of place. The technical topics are always thought provoking. The personal touches are always endearing. Hearing about the gaming community through their developer lenses is always great. Lostcast is just… great.

Thanks, Lostcast, for everything. Thanks and farewell.

Learning to LÖVE: We’re Gonna Make Pong

This entry is part 2 of 2 in the series Learning to Love

This is Lesson 2 in my series on getting start making games Learning to LoveIf you need to get your computer setup for making games with the LOVE framework, see Lesson 1:  Learning to LÖVE: Getting Started with LÖVE.

At the end of the first Lesson we created a blank project in a new folder with a single empty file called main.lua  in it. This was the minimum setup for LOVE to run a game, but it just opened a empty window with that blank file. We’ll fill that file up with our first game now.

We’re going to make pong!

This is the actual version of PONG we’re going to be making today. The paddle on the right is the player, controlled by the up and down arrows. The paddle on the left is an AI player that tracks the ball, trying to bounce it back at us. The score will be kept at the top of the screen, and the ball will increase in speed as the play continues, getting trickier and trickier to follow.

If you’ve never programmed before, don’t worry. We’ll walk through every step one at a time. You’ll be able to learn along the way.

You build anything by breaking it down into little steps. Any game, even one as tiny as PONG, is too big to make all at once. Instead, we’ll start with a very simple thing, and we’ll keep adding pieces until we have our PONG game. Here are the steps we’ll be taking to build the game.

  1. Draw a simple rectangle on the screen. This will be our ball.
  2. Make the ball bounce around the screen
  3. Make the player and AI paddles on the sides of the screen, controlled by the computer and the player.
  4. Make the ball bounce off the paddles and not the sides of the screen.
  5. Add a score counter and we’re done.

Let’s jump into step one!

Step 1: Drawing Simple Boxes with LOVE

Let’s start learning some basics. We’re going to draw a square! Enter these simple lines and run your game.

(If you need a refresher about how to run the game, which we covered in Lesson 1, just press that big play button in the top-left toolbar of your Atom editor!)

This is your very first actual LOVE program, so lets break down what it did. If you ran it, you’d see this screen (I’ve drawn on the screen to explain what’s happening).

We decided where to draw the box by naming two numbers BALL_X  and BALL_Y . We decided how large to draw it by naming two numbers BALL_WIDTH  and BALL_HEIGHT .

We can tell LOVE to draw a rectangle for us using the love.graphics.rectangle()  command. (The words “command” and “function” are largely interchangeable) We use the numbers we named (those are called “variables”) to tell the command how we want to draw the rectangle.

Games draw to the screen very fast. Usually the screen is drawn 30 to 60 times every single second. Your game is no different. LOVE needs to know what code in your program draws everything so that it can re-run it every single frame.

Hey, Wait A Minute… Why “30 to 60” instead of an Exact Number?
Good question, intrepid reader!

Your game has a lot of work to do moving things around and handling input and doing all the things to make your game work. This draw function is called in between that work, when the game has a small break to draw()  everything to the screen. If the computer can’t draw fast enough, draw() will be called less often.

That’s how we get frame-rates (or FPS) in games!

We wrap our drawing code into our own function called “ love.draw() ” which LOVE will call every time it needs to draw to the screen. Functions are commands that do a certain job.

love.graphics.setColor()  is a function to tell LOVE what color we want to draw things to the screen with. We use love.graphics.setColor(255, 255, 255) to set the color to white.

love.graphics.rectangle()  is a function we use and love.draw()  is a function we create.

Of course, that’s much too big for a PONG ball, so make it a bit smaller before moving on. Feel free to play around with all four numbers to see how it draws different rectangles on the screen before continuing on to the next part of the lesson.

Step 2: Move the rectangle with a velocity

Now that we can draw a simple square, lets start turning this into our pong game. We’re going to start it moving.

Now, we’ll move it. The love.update()  function is the next command we’ll create for LOVE, a lot like love.draw()  and also called many times a second. Instead of drawing to the screen, this function is called when LOVE wants us to update all the data in our game. This is when we’ll move characters who are moving on the screen, change colors to make lights flash, and check if lots of moving objects hit each other.

If we change the value of the BALL_X variable the square will move along the screen. Run the game with this added to your mail.lua file.

You’ll see the ball moving quickly across the screen. Probably too fast.

Every time LOVE calls our love.update function we move the ball by 25 pixels. Unfortunately, because this could happen any number of times a second, we don’t actually know how maybe times this happens or fast it will move. We can fix that!

Let’s say we want the ball to move 25 pixels per second. The function is passed an important value we can use: the amount of time that passed since the last time it was called. We can use this to figure out exactly how far to move the ball every frame. We’ll go ahead and move it in two directions, as well, by adding a line to change BALL_Y the same way.

All we’ve changed is multiplying the movement by this value we’re given, and now our ball will move at a steady pace. If you change the value 25 you’ll make the ball move faster or slower.

Bound the rectangle on the screen top/bottom

The first thing you might notice is the ball just flying right off the edge of the screen! That’s not going to make a very good game of pong. Let’s start to keep it inside the game area.

This version of our update function moves the ball in the down-right direction. We’ll make the ball bounce against the bottom edge. After we’ve moved the ball we want to ask, “Has it reached the edge of the screen?” and, if so, we want to make it bounce.

Now, because we need to be able to change the direction of the ball we need the direction its moving in to be a variable instead of just a number. We’ll make separate variables for the movement along the X axis and Y axis.

How do we change the direction the ball is moving in? We just make the number negative. If BALL_VX or BALL_VY are -100 instead of 100 then we’ll be subtracting from BALL_X and BALL_Y every time our update function is called.

With the ball moving based on our new variables, we can add a few lines to check if the ball has moved past the left side of the screen, because that’s the direction the ball starts moving.

…of course, we want to make it bounce on both sides…

and we want to bounce on the top and bottom of the screen, as well!

 If you need to catch up, here’s the complete main.lua code you should have at the end of Step 2

Step 3: Adding both Computer and Player Controlled Paddles

We’ve got the ball bouncing around the screen, but we need to do something with it, so we’ve got to create the Player and Computer paddles. We’ll be giving the player the ability to move the paddle on the right side of the screen up and down. The computer will move the other paddle to track the ball as it bounces around the screen.

First, we’ll draw the paddles. This works just like drawing the ball. Let’s add some more variables at the top of our code to track the placement and speed of the paddles.

And we add two lines to love.draw()  to put the paddles on the screen.

They’ll try to hit the ball with it to keep it from hitting the edge. So, we’ve only got two directions of control to implement and we’ll start with wiring up the down button.

The love.keyboard.isDown() function will tell you if a button is being held down by the player. Ask it if the player is holding the down button and, if they are, move the paddling down. We use the same trick of multiplying by dt to ensure a smooth speed.

…and we’ll do the same thing for the up button to move the right-side paddle up.

If you need the code as it should appear at the end of Step 3, here it is:

Step 4: Bouncing the ball off the paddle

Now comes the really important bit: making the ball bounce off both of our moving paddles. Bouncing on the screen edges was pretty easy, relatively, because those are fixed and stretch the full size of the screen. The paddles are smaller and move and we have to let the ball bounce on them but pass to the edge if they miss.

Let’s look at some measurements we can use in a typical game of PONG. We’ll focus on the player paddle on the right, first.

BY: How far is the ball from the top?

PY: How far is the paddle from the top?

BX and PY: How far are they from the left side?

25: The size of the ball

150: The height of the paddle

Now, we just ask three questions to find out if the ball hits this paddle:

Is the ball far enough to the right to touch the paddle?

Is the ball below the top of the paddle?

Is the ball above the bottom of the paddle?

Here’s how our three questions translate into a simple if  statement to determine the collision:

Bouncing on the left paddle is almost the same.

The ball still bounces against all the edges of the screen, but now it bounces against the paddles as well. Of course, the point of the game is that you have to hit the ball with the paddle, so what should happen when the ball touches the left or right edges? It shouldn’t bounce. Instead, it should pass through the edge and then re-appear in the center of the screen for a new round to start.

Here’s how we’re currently bouncing the ball on the sides of the screen:

We want to allow the ball to pass a little beyond the edges, so we want to change the values 800 and 0. And, we’ll replace the line that bounces with a line of code to move the ball back to the start.

This step was a bit simpler than the previous ones. That’s it. It wasn’t much to add, but here’s the complete code at this end of this step:

Step 5: Keeping Score

Our last step is adding a little bit of polish by keeping score for the two players. Just like the original PONG we’ll put the scores at the top of the screen and they’ll count each time a player scores a point.

Before we keep score we need to add two new variables to keep them in. The scores will start at 0, of course, so add them to the top of your file with the other scores:

Right now we just reset the ball when it passes beyond one of the side edges:

So, we’ll add some lines here, but we need to check which side the ball went through, because now it matters. We need to know which player to award a point to.

And, the very last step in making our game, is adding just a few more lines to the love.draw()  function to use a new LOVE function called love.graphics.printf() . This lets us draw text on the screen. Our variables LEFT_SCORE  and RIGHT_SCORE  are numbers, but we have to give printf()  text and we convert them with the tostring()  function, which you can see in the code here:

Wow.

You just made a whole game. I’m impressed with you! Give yourself a pat on the back. Call someone over to your computer to show it off! Tell your friends about it!

You should feel good about taking this first step. You are a game developer.

The Learning to LOVE series will continue. I hope you enjoyed it so far, and if you want to learn more you should subscribe to my newsletter for all things gamedev related. The newsletter is from my little game studio Stonebird Games, but its a big focus on the making of games. Sign up for new updates about Learning to LOVE and my other game dev projects!

Complete Source

Here’s the complete game running! You made this! If you need it, the complete code is below. You can mess around with it, and I encourage you to do so. Try tweaking the BALL_START_SPEED  or the height of the paddles. Try making them shorter for a challenge? Maybe see what happens if the ball gets even faster with every bounce off the paddles.

Play around, learn more, come back for more LOVE lessons in the future!

 

MDN Brings Browser Vendors To One Table

Have you heard the great news about documentation on the web? Mozilla, Google, Microsoft, and Samsung have made a join commitment to directing documentation focus for their browsers’ web standards to the existing Mozilla Developer Network (MDN).

This is a huge step for the web, for a number of reasons.

First, this commitment means that, with these four vendors committing to combining their documentation, differences will be a lot more obvious. I think this is going to create a big incentive to the vendors towards both compliance and matching pace with each other.

Second, just like the great resource of caniuse.com, developers are going to have even more one-stop shopping for sizing up the differences between browsers on a particular feature, determining when new toys are available consistently enough to use on broad-usage projects, or finding the nuances of working around those differences to provide stable experiences to all your users, regardless of their devices and software.

Lastly, and I think most interestingly, this news is amazing for all that it isn’t. It isn’t particularly shocking or surprising. It gives us a new leg up on cross-browser development, but the gaps it closes aren’t actually that large to begin with. Five years ago? This would have much bigger news then. Ten years ago? This would have been essentially unthinkable. We’ve come a long way to get here, but the vendors cooperation has improved so much that this news, while great, honestly feels almost inevitable.

That feeling gives me a lot of hope for the success of this initiative!

Learning to LÖVE: Getting Started with LÖVE (on Windows)

This entry is part 1 of 2 in the series Learning to Love

Learning to LÖVE is a series of tutorials and articles teaching the ins and outs of building games with the LÖVE engine. LÖVE is a great tool for people new to building games. It can serve seasoned developers, too, as a straight forward way to bring game ideas to life.

This first installment of Learning to LÖVE will get you up and running quickly with LÖVE installed, as well as a recommended editor and extensions that make working with LÖVE games easier. You’re going to install LÖVE to run your games, the Atom text editor to work on your games, and several extensions to Atom that help you write Lua, the programming language LÖVE uses, and to run and test your games.

This targets Windows users, but most of the details will work on other platforms. OSX and Linux versions of this article should be available at some point in the future.

Let’s get started by installing LÖVE itself first.

You can get LÖVE from the project’s website love2d.org. The downloads are first and foremost on the main page, so you can easily find them! I recommend grabbing the “64-bit Installer” option. This will be the easiest to work with, including with the extra tools we’ll be adding next.

Just walk through the installer steps and you’ll have LOVE installed in no time.

Next, we’ll install Atom, our text editor of choice. I’m recommending Atom for three crucial reasons for people new to programming:

  • Atom is a free text editor

  • Atom is easy to use

  • Atom has great extensions, including ones that make working with LÖVE a breeze

Just like LÖVE itself, the Atom website makes the download option front and center. You can find it at atom.io, so go there and download the installer now.

Atom doesn’t even require any installer steps. It will install automatically, so just wait for it to complete. Atom is larger than LÖVE itself, so the wait is just a bit longer.

When Atom is done installing, it should open itself automatically. If it doesn’t, you should find it in your Windows menu, so go ahead and open it. You’ll be presented with a lot of first time options. If they are daunting, don’t worry: I’ll walk you through the things you need today.

The first thing you’ll see is the Atom settings and a collection of “Get to know Atom!” options to make it easy to start customizing. The first thing we want to do is “Install a Package” so we click “Open Installer”, search for “love-ide”, and click the “Install” button when the package comes up in the search results.

Atom will run through the package installation steps. It will ask you a few times if you want to install dependencies. Answer “yes” each time. These are just other packages that the one we want depends on to do its job of making LÖVE easier to work with.

When all of these packages are completed you can close the Welcome tab on the right and focus on the settings. Click the settings button on the love-ide package, which should still be present. We’re going to make some small customizations to ensure it works with the version of LÖVE we have installed.

The main thing we want to do is configure Atom to use the debug version of LÖVE , so that we can get information when our code fails. In the first setting, which is labeled “Path to Love Executable”, enter this: C:\Program Files\LOVE\lovec.exe

That’s all the customizations we’re doing right now!

This article is all about getting setup. We’ll make our first game in the next installment, but I’ll at least show you the first tastes of what the process will look like. So we’ll create an empty project and run it to see the most basic LÖVE program run with an empty screen, but its a start!

Click the “File” menu in Atom and select “Open Folder…”

When the dialog appears, click the “New folder” button in the top left and name your first project. We can call it “My First Love Game”.

Now we just want to create a standard file for LÖVE called “main.lua”. All LÖVE games begin with this file, the main script that runs your game. Right click on your project folder and select “New File”, name the file “main.lua” and press enter.

Now you can use love-ide’s LÖVE run button, in your toolbar on the top left, to run this empty script to see the start of your first game run… sort of! It’s just an empty window for now, but you’ll be packing lots of great stuff in that space soon enough.

In the next installment of Learning to LÖVE , we’re going to take this empty script and fill it with our first real game. I hope you’re excited to get into the world of game making!

Publishing ES6 Modules on NPM

I had an adventure over the last couple days with ES6!

There was a pattern I’d already used in a few of my React projects to make ES6 classes a little nicer. ES6 did a lot to make working with this mechanics nicer, but there was a still a gap that bit me: the sugar provided by ES6 classes don’t extend to keeping method bound to instances of the class.

Maybe you, like me, would expect this to work:

But, like non-class methods on any regular Javascript object, onClick will loose its binding to the Counter instance. There are a few existing solutions to this, but I wanted one that didn’t change the syntax of defining a method on these classes.

Enter AutoBind, via my new NPM module es6-class-auto-bind:

You can read all about the AutoBind class [at its NPM readme](https://www.npmjs.com/package/es6-class-auto-bind) and you can read on to learn about what I learned to publish this ES6 module on NPM, consumable by other ES6 (and even ES5) code.

The Problems of ES6 on NPM

For the moment, NPM is a tool for distributing and installing ES5 modules. While you can point it at any types of files you want (some people have even used NPM to distribute C libraries!) the mechanisms that install and then import those modules in NodeJS (or Browserify) are expecting ES5 modules, so they won’t do your users any good.

There are two problems we’ll face shipping ES6 code directly.

First, most of the ES6 code we might ship would be completely useful for consumption by ES5 code. My choice of ES6 shouldn’t prohibit anyone from consuming my libraries. We want to publish something that both new ES6 and legacy ES5 code can make use of without caring much about what’s inside. And, we want to do so without carrying build constraints on our users, like requiring they integrate BabelJS into their pipeline when they haven’t done so already.

Second, for those consumers of our module who already are using BabelJS or another transpiler to ship their ES6 to ES5 runtimes, importing ES6 code installed by NPM is probably not going to work out of the box! Browserify here is a big culprit, refusing to apply configured transform plugins to packages installed from node_modules/, only to those from your own local project.

Now, I understand Webpack may be better about enabling this usecase, but I don’t want to impose that move to people still on Browserify (and I still want to support ES5 users), so I wanted a solution that works for everyone.

How To Combine Packaging and Transformation

The solution is to tranform our ES6 module to ES5 before publication, and idealy to automate this. We want to transform it into an ES5 version of itself and tell NPM to publish that version of our module, instead of the original ES6 version. Here’s how we do it.

We’ll put our two versions into a src/index.js and build/index.js. Transforming the first to the second is straightforward with BabelJS, which we’ll install first:

Now we have both versions, and we only need to tell NPM what we actually want a consumer to get when they require()or import it.

Great! But we still need to make this happen automatically any time we issue an npm publish, never allowing us to publish a version that isn’t compiled from the most recent version of the ES6 source.

We’ve defined two npm run scripts now: compile and prepublish. We can run npm run compile to test our preparation any time, and NPM itself will invoke prepublish before any new version you attempt to upload via npm publish. We’ve now configured our module to transform from ES6 to ES5 before publication to NPM, where it is consumable by any other project that needs it!

We’re almost done at this point. There is a last step we can take to make the whole process more consistent between ES5 and ES6 norms. The ES6 module syntax’s export statement is largely comparable to exports.member = somethingstatements in NodeJS’ ES5 modules, and BabelJS will transform them appropriately. But export has a special form for exporting one member as a default, to be handed to an importing module when it only asks for a single thing from the module.

The problem is BabelJS transforms this by exporting these defaults with the obvious name “default”, and accesses the .default member of a module when performing a default import. But, this means ES5 code would need to access the .default member explicitly, with the unfortunate requires() invoking as require(“es6-class-auto-bind”).default. We’d like to get rid of that ugly .default at the end, obviously.

It turns out this is a behavior BabelJS did have but changed. It is also a behavior we can restore through a plugin that re-implementes the deprecated behavior. I think allowing it to be optional like this is just fine. We just need to install the plugin

And change our compile script to enable the plugin

And, that’s it. Everything works great now. This is how I was able to ship my ES6 AutoBind class via NPM and install into other ES6 classes, seamlessly building my ES6 code across packages. Very exciting!

Here’s the whole portion of the package.json necessary to make this work.

Stay subscribed for follow up posts on the subject, as I dig into how to expand this to:

  • Ship a copy of the ES6 code in parallel and pull that into the project’s own transform options
  • Understand how to expand this approach to packages with more than one module