Menu

Colin Devroe

Reverse Engineer. Blogger.

Attending September’s NEPA.js meetup

On September 12th, NEPA.js held its September meetup. Anthony Altieri presented on beacons – the typically small Bluetooth devices that “chirp” some very basic information multiple times per second allowing app developers to understand the proximity of a user. This allows for things like understanding where a shopper is in a retail space.

His overview of the devices, the spec, some of the software, and the differences between iOS and Android, and iBeacon and Eddystone – was a really nice introduction into the space. He did a great job.

I learned a lot during his presentation. Thanks to him for putting it together.

If you haven’t yet been to a NEPA.js and you live in our area – I implore you to check one out. It is consistently attended, always fun, and isn’t always focused solely on JavaScript. But even if it was, it is worth your time.

Matt Mullenweg on Automattic’s use of React

Matt Mullenweg:

I’m here to say that the Gutenberg team is going to take a step back and rewrite Gutenberg using a different library. It will likely delay Gutenberg at least a few weeks, and may push the release into next year.

Automattic will also use whatever we choose for Gutenberg to rewrite Calypso — that will take a lot longer, and Automattic still has no issue with the patents clause, but the long-term consistency with core is worth more than a short-term hit to Automattic’s business from a rewrite.

This is a big blow to React. The framework will still be massively popular and adopted but the number of developers in a thriving ecosystem like Automattic’s products – like WordPress – that now have to move onto something else is a big blow. Automattic’s continued use of React would have meant thousands of jobs for a long number of years.

As usual, Mullenweg sees the longterm angle, and weighs that against the core principles upon which his company was founded, and I believe he’s taking the right path.

Side note: I still see so many developers that deal with WordPress day-to-day that haven’t yet started learning JavaScript in earnest. Mullenweg himself has urged the WordPress community for the last several years to invest in learning JavaScript. So, if you haven’t already… jump in.

Tom Dale: “Compilers are the new frameworks”

Tom Dale, Senior Staff Software Engineer at LinkedIn and co-creator of Ember.js, in a post where he argues that compilers are the new web frameworks:

Native code tends to have the luxury of not really caring about file size—a small 40MB iOS app would get you laughed out of the room on the web. And AAA game titles accept minutes-long load times in exchange for consistent 60fps performance, but I shudder to think what a 30 second load time would do to the conversion rate of your e-commerce site, 60fps or not.

While I agree with most of his post, that compilers are becoming increasingly more a part of a web developers workflow and thus becoming very important to learn, this particular bit isn’t a fair one-to-one comparison in my opinion.

Web apps do not need to pre-load every single asset onto the device prior to running. If you were to weigh a fully native app next to its counterpart web app* you’d likely get a very similar result. It is just that a native app is downloaded mostly all at once and a web app can be loaded as needed.

But his point remains, more and more web apps are looking more like native apps. They are compiled, loaded, and completely obfuscated from the source code they originally started out at. I’m not sure if I feel this is good or bad for the web. But I do know that the barrier to entry in web development is higher than ever.

* Most web apps that have a direct counterpart on a mobile platform share lots, if not all, code these days so these comparisons are getting tougher and tougher to do fairly.

A unique color for every address in the world

A recent, yet-to-be-announced client project had me designing a mobile app interface that dealt a lot with showing locations and events that are happening at certain locations (how is that for vague? sorry).

While I utilized the brand’s colors to represent certain sections of the app I wanted the app to have tons of colors in order to portray a sense of fun throughout the app. But how could I incorporate pinks and yellows and bright greens without the overall brand disappearing?

After toying with a few design ideas I had an idea to create a unique color for every address in the world. This would result in two benefits; first, each location was then branded as a color, and second, every user would see that location as the same color. If I were a user of the app here in the US and I flew to Spain and looked at a location for an event  there, I would see the same exact colors representing that address as the person that lived in Spain and created that event.

Since I wasn’t to be the developer of the mobile application I wanted to avoid the possible pushback this idea might receive from that team. I didn’t want to add burden to the other people on the project by showing a design mockup and a set of requirements and then walking away. I wanted it to have zero overhead for the developers.

One of the solutions I discarded was generating a random color each time an event location was added to the service and then store the color for that address in a database. While this solution is relatively simple to implement it was no good. It adds more work for the developers and they have to maintain the datastore indefinitely. Several other ideas with the same caveats came to mind and I quickly tossed them into the bin.

Once I eliminated all of the ways I didn’t want to solve this problem – the solution came pretty quickly.

Since every address is already unique, I just needed to find a way to represent an address that could be turned into a color. In other words, I wanted the address itself to represent a unique color. And I wanted to do it in realtime as the application’s UI loaded.

So I jumped into JavaScript and began working it out. Here is what I settled on:

This solution allows for just over 16.5 million colors. Far more than this app will likely require during its lifespan.

Here is a demo of the process and if you view the source you can see the code at work. It is fairly simple to follow.

Oh, there was an issue that I ran into with this solution that was fun to solve. If the background color that was generated was too dark the text became hard to read. So digging around I found a way to determine the luminosity of the background color and thus change the text to something a bit lighter in those instances. That too is shown in the demo.

I was then able to repurpose this demo code and give production-ready code to the developer that is going to ship in the app. When that ships I’ll write more about it.

Attending the August NEPA.js Meet up

The NEPA.js Meet up is really hitting its stride. Each meet up is pretty well supported – even in the summer – and the camaraderie and general feeling around each event is pretty great. Also, the Slack channel is pretty active.

If you’re within an hour or so of Scranton I’d recommend joining the meet up group, jumping into the Slack channels from time-to-time, and attending at least a few events per year. If you need help with any of these things send me an email.

Also, within the past few weeks we’ve seen a new group spin out of the NEPA.js group. A more general meet-and-work-on-stuff type of group created by Den Temple. This event fills the gaps for when there isn’t a NEPA.js group event.

This month’s presentation was by Ted Mielczarek. Ted works at Mozilla on build and automation tools for Mozilla’s primary product Firefox. He has, though, dabbled in a variety of other things at Mozilla like crash reporting and the gamepad web API. It was his experience building this API that spurred this month’s topic; Web APIs.

I remember jumping onto the web in the 90s and being blown away when I was able to put animated GIFs of X-Wing fighters on my personal Star Wars fan page. Today, web browsers support a variety of Web APIs that make the open web a true software development platform. There are APIs to control audio and video, to connect to MIDI-enabled devices, to connect to Bluetooth, VR and – of course – to allow for game controller input. There are lots of others too.

Ted did a great job showing demos of many of these APIs. Just enough for us to get the idea that the web has matured into a powerful platform upon which just about anything can be made.

Thanks to Ted for the work he put into creating the presentation and to all the attendees for helping the NEPA.js community thrive.

Presenting at the July NEPA.js Meetup

Earlier this week my Condron Media cohort Tucker Hottes and I presented at the July NEPA.js Meetup. Our presentation was about automation and all of the things we can automate in our lives personally and professionally. And also how we employ automation in our workflows for creating applications and web sites using our own task management suite.

Here are just a few examples of reproducible tasks that you can automate that perhaps you haven’t thought about:

  • Your home’s temperature
  • Applying filters to multiple photos at once
  • Social media posts
  • Combining many files together into one
  • Deleting unused files
  • Calendar events

There are countless others. Perhaps you’re doing some of these things now. You might set a reminder for yourself to clean the bathroom every Tuesday. Or, your using a Nest to control your home’s temperature based on your preferences.

But there may be others that you’re not doing. Posting regularly to social media can seem daunting to some. But automating those posts can make it much easier to set aside time to schedule the posts and then go about your day. Or editing photos or video may never happen because you don’t have time to go through them all and edit each one individually. But these are tasks that can be automated.

We showed a quick demonstration of automating the combining of multiple text files using Grunt. There are a lot of ways something like this can be useful. Combining multiple comma-separated value (CSV) files that are reports from many retail locations, web development, and others.

Then Tucker provided a list of all the tasks we do when we get a new client at Condron Media. The full list can take a person up to 1.5 hours to “start” working on that customer’s project. So we’ve begun working whittling away at that list of tasks by using another task manager called Gulp. We call this suite of automation tasks Bebop – after one of the thugs from Teenaged Mutant Ninja Turtles.

Bebop is separated into the smallest tasks possible so that we can combine those tasks into procedures. Creating new folders, adding Slack channels, sending Slack messages, spinning up an instance of WordPress, adding virtual hosts to local development environments, etc. etc. Bebop can then combine these tasks in any order and do them much quicker than a human can clicking with a mouse. We estimate it will take 1 minute to do what took 1.5 hours once Bebop is complete.

Another benefit of automating these types of tasks is that you can nearly eliminate human error. What if someone types in the wrong client name or forgets a step in the process? Bebop doesn’t get things wrong. Which saves us a lot of headaches.

Here is the example Gulp task that we created to demo Bebop to the NEPA.js group.

We then asked the group to take 5 minutes and write down what they would like to automate in their lives. The answers ranged from making dog food to laundry to simple development and environmental tasks. Every one in attendance shared at least one thing they’d like to automate.

Tucker and I had a blast presenting but we enjoyed this final session the most. Similar to my event suggestions to Karla Porter earlier this year, I find that the more a group interacts with one another the more I personally get out of a meetup or conference. Presentations can be eye opening but personal connections and calm discussions yield much fruit for thought.

Thanks to everyone that showed up. I think we had 14 or 15 people. The NEPA.js community is active, engaged, and I’m very happy that it is happening in Scranton.

Attending February’s NEPA.js meet up

NEPA.js is quickly becoming my favorite tech-related event to attend.

On Monday night at the Scranton Enterprise Center a solid group of attendees listened and shared in Jason Washo’s presentation on whether or not to handwrite or generate JavaScript through transpiling. Jason is a big believer in transpiling JavaScript but he kept his presentation balanced by providing both the pros and cons of doing so. He also opened the discussion up to the group several times for feedback throughout his presentation. His presentation was very good, but the discussion was even better.

Afterwards topics began to fly regarding next month’s topic, future topic ideas, and how everyone really enjoys these meet ups. If you’ve been watching from your chair and thinking about attending – please do. You won’t regret it.

Attending January’s NEPA.js meet up

Aaron Rosenberg NEPA.js

Photo: Aaron Rosenberg presenting an intro to Node.js.

January’s NEPA.js meet up, the second monthly meet up for this group, was held on Tuesday evening at the Scranton Enterprise Center. This group, though only a few months old, is starting to get its legs underneath it and it is really great to see the community building.

The meet up’s discussion was centered around an introduction to Node.js and it was extremely well presented by Aaron Rosenberg. Aaron did an excellent job explaining the project’s raison d’être, history, and growth. One bit I especially liked was him showing how the browser’s JavaScript engine processed requests using Loupe. All-in-all an excellent introduction. (Link to presentation slides forthcoming. Check back here.)

Following Aaron’s presentation was Mark Keith showing some real live coding of a simple Node app using Express, a framework for building Node web apps, which quickly devolved slightly into discussions on scope, globals, “this“, etc. which was all good because the attendees were steering the conversation.

After the two hour meet up we made our way through the parking lot to Ale Mary’s for a beer or two. I’m looking forward to February’s meet up.

Thanks goes to Aaron and Mark for putting together the presentations and to tecBRIDGE for the pizza.

Attending the Wilkes-Barre Programming meetup

Osterhout Free Public Library

On Saturday I braved the frigid temperatures and attended a Wilkes-Barre Programming meetup at the Osterhout Free Library in downtown Wilkes-Barre.

I arrived a few minutes late – it was Saturday so of course I had to make myself some breakfast, enjoy my coffee, watch a little YouTube prior to getting out in the elements – and then I couldn’t find the room the meetup was in at the library. Once I found the group there was already 6 attendees and they were over an hour into their programming.

One of the attendees proposed a problem to be solved; convert a number into a Roman numeral using Python. I have little-to-no Python experience, and unfortunately not much was discussed at this meetup regarding the language (since it wasn’t for beginners) but I decided to try my hand at solving this problem in JavaScript. Here is my attempt (though incomplete). It can do the thousands and hundreds. I’d need a little more time to do the tens and singles but I ran out of time at the group.

I was happy to see this small group meeting in Wilkes-Barre. Some of the attendees mentioned they’d be visiting the #nepaJS meetup happening on Tuesday, which would be great. We need a lot more of these smaller groups and we need them all to be connected to the larger NEPA Tech group. In larger metropolitan areas these smaller groups would be hundreds strong and so consolidation wouldn’t be needed. We don’t have that here. So we need as much effort to be consolidated as possible. These small groups are where skills are honed, where partnerships and companies can be formed, where careers are forged. If you are someone that works in technology please consider joining one of these smaller groups. Even if you aren’t into programming. As they grow I’m sure they will end up fragmenting into more specific groups for the areas you’re interested in. The more support the better.

Attending the NEPA.js meetup

NEPA.js

On Tuesday I attended the first monthly NEPA.js meetup at the Scranton Enterprise Center. Mark Keith, a JavaScript developer who somewhat recently moved into the area, was the organizer and TecBridge – who organizes the NEPA Tech meetup group – helped to coordinate, host, organize and provide pizza for this brand-new group.

The common refrain in our area is that those of us who build software products, enjoy a good bit of nerdery, or want to reach out and socialize with people who know what a npm package is… are somehow alone. That simply isn’t true and the first NEPA.js meetup proved that. Twenty-five or so people made it out to this first meetup even with the snow. There were young and not-so-young, men, women, and even those that didn’t know what JavaScript was but knew it was important for them to understand it.

After some introductions Mark did a great job of giving an overview of what JavaScript the language was and how it can be used. He kept it high-level and, though I’m sure some didn’t understand everything he said, surely they left knowing more about what JavaScript is then when they walked in. We also had those in the room that have been developing with JavaScript for years and years – and even one Mozilla team member.

The group meets again next month and will continue to do so the second Tuesday of each month. The group also has a Slack channel so if it you want in just ping me on Twitter.

Hacking rather than waiting

Yesterday afternoon Sarah Pressler retweeted Jono Young’s request for a plugin that would add a submenu to the WordPress’ Admin with the current pages for the site under the Pages menu. This would reduce the number of clicks to get to the page editor.

I was waiting for an upload to finish and I thought, given the code I have laying around from other projects, I’d be able to supply Jono with something passable for what he needed. Though it is far from what I would recommend using, it is a start.

Here is what I did:

  • I used get_pages to get a list of WordPress pages the were published.
  • While looping through each page I used add_submenu_page to add the page titles under the Pages menu
  • I used JavaScript to replace the HREF attribute on the links to link to the page editor

That last step is the hacky part in my opinion. add_submenu_page() asks for a function name to call to build the page for the menu item when it is clicked. In other words, for each item on the Admin menu there is a corresponding function that will show you the page that it results in. But I didn’t want to create a new page, I wanted the link to go to the page editor.

I dug around for five minutes or so and I didn’t see an apparent way to change the links for the page titles (though I’m sure there is a better way if I had the time to continue looking) and so after the page loads I use JavaScript to replace the attributes with links to the page editor.

Nowhere near perfect but, in a pinch, it is one step closer to what Jono wanted. Hopefully he or someone else can build upon and it make something a little more reliable and less hacky.

You can see the source on Github.