I am surprised and excited to see the news that Facebook is going to drop the patent clause that I wrote about last week. They’ve announced that with React 16 the license will just be regular MIT with no patent addition. I applaud Facebook for making this move, and I hope that patent clause use is re-examined across all their open source projects.
Interesting outcome. Here is more context.
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.
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.
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 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.
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.
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.
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:
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.
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.
NEPA.js is quickly becoming my favorite tech-related event to attend.
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.
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.
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.
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.
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.
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:
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.
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.