Menu

Colin Devroe

Photographer. Podcaster. Blogger. Reverse Engineer.

John George shares a solution

John George, fellow NEPA.js attendee:

I’m writing this because I discovered the hard way that .NET Core’s ‘dotnet run’ command is NOT meant to be production ready. My biggest headache was that my website shut down when I exited my shell. Not even the ‘disown’command would dissociate the running service from the user.

Posts like this by John often do not get enough attention. While it may not be applicable to you right now – dozens, hundreds, or perhaps thousands of people searching for this issue over the following months and years will be very glad that John took the time to do the write-up.

Kudos to him. More developers should write about their solutions.

Brad Frost on “full-stack developers”

Brad Frost:

The term “full-stack developer” implies that a developer is equally adept at both frontend code and backend code, but I’ve never in my personal experience witnessed anyone who truly fits that description.

In many of the descriptions I’ve seen it goes even further than that. Sometimes full-stack developer refers to someone who can also administer server architectures or cloud services or do database work.

There are certainly a number of people who can fumble their way through all of these things. I consider myself one of them. But I wouldn’t call myself great or even very good at any one of them. There is nearly no one that is great at all of these things. I’ve only seen perhaps one or two in over 20 years of banging away at this keyboard.

This is also an excellent point from Brad:

Large organizations have the ability to hire specialists, which is why I get so confused why so many companies proudly declare they only hire full-stack developers. Having team members that can own the frontend experience is a good thing. Having team members that can own all things backend is a good thing. Having everyone work together to create successful products is a good thing.

No one should be ashamed that they are very good at one thing and not as good at another. Embrace that fact and become an expert.

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.

Python is blowing up

David Robinson, not The Admiral, for Stack Overflow:

We recently explored how wealthy countries (those defined as high-income by the World Bank) tend to visit a different set of technologies than the rest of the world. Among the largest differences we saw was in the programming language Python. When we focus on high-income countries, the growth of Python is even larger than it might appear from tools like Stack Overflow Trends, or in other rankings that consider global software development.

I don’t think I would have guessed this.

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.

I can work on anything I want

One of the most enjoyable aspects of working on your own project is that there is so much to do. That may seem strange, why would I want to have so much to do? But if you look at it a different way it becomes a much more enjoyable experience.

Whenever I sit down to work on my pet project, a new iOS app, I can choose what I’m in the mood to work on. Perhaps I’m in the mood to work on the branding, editorial, licensing, or marketing? Or, would I prefer to hunker down into some Swift programming and refine the datastore, algorithms, animations, speed, etc of the app? Or perhaps I’d like to identify key strategic partners for my product launch or look through beta user feedback or do some artwork?

You see the point? Yes, there is a lot to do. And it can seem overwhelming if you allow it to be. But, no matter what type of mood I’m in I can make some progress on the project nearly every single day. And I’m having a ball so far.

Observations on building my first iOS app in Swift

In early June I decided I wanted to learn iOS app development using Swift.

I’ve made a lot of progress over the last month, building two apps that I can use on my own phone, and one app that I’m now in beta testing via TestFlight with a few friends. Over the last month I’ve made some observations on the process of building an iOS app, the Swift programming language, Xcode, iOS frameworks, and the various other bits needed to make an app. I thought I’d take the time to jot those down.

These are in no particular order:

  • Swift is growing on me rather quickly. The idea behind Swift has always interested me, but I hadn’t really given it a try until now. Like any new language you need to work with it for a time before some of the things that you may not like about it, you end up seeing the wisdom in.
  • I’m very glad I waited until Swift 3 before trying it in earnest. The tutorials I’ve come across for earlier versions make it clear the language has matured in a short period of time.
  • Using Storyboards in Xcode is not intuitive whatsoever. I know many people avoid them altogether (from what I’ve seen on YouTube). Unless you watch someone build a Storyboard you’d likely never, ever just figure it out.
  • iOS frameworks are bulky. It is no wonder so many apps are so big. Just including one or two frameworks for my very simple first app ballooned the app to over 15Mb.
  • That being said, iOS frameworks are very useful. With just a few lines of code you can get something working quickly.
  • Playgrounds are very useful to learn Swift.
  • The Playgrounds compiler can become stuck rather easily. Especially if you paste in a bunch of code from your project to mess around with and get it to work. I’ve had to restart Xcode several times.
  • Xcode has crashed on me a few times over the last month. Crashes on macOS (and also most Apple apps) are very rare. So to be working on something so fragile seems out-of-character. Especially with how simple my apps are currently.
  • Auto Layout baffles me still. I have a working UI for one of my apps that works across multiple device screen sizes. But it is far from what I’d want to ship with. I’ve watched a lot of videos on how to use Auto Layout but I still can’t make heads or tails of it. I’m waiting for the moment it clicks.
  • The connection between labels and buttons and other UI elements in your Storyboard and your Controller class is far too fragile. You should be able to rename things, delete things, move them around without completely blowing everything up and starting over. Example: If I CNTRL+Drag a label onto my Controller and create an Reference Outlet for it… I should be able to rename that Outlet without needing to CNTRL+Drag again. I don’t know how, but somehow.
  • Did I mention that Auto Layout baffles me still?
  • Building and deploying an app to iTunes Connect in order to add to the App Store or Test Flight is an entirely un-Apple-like experience. There is no Step 1, Step 2, Step 3 type of workflow. Similar to Storyboards it is not something you can figure out – you must watch or read to learn. It feels like it was never designed by a Product person.
  • Building an app that resides on a device like the iPhone is an amazing experience. While I’ve always been able to load my web apps on a phone, and I’ve built some apps that use a WebView to deploy across multiple platforms, this is the first time I feel like I’m touching my app when I use it. There is nothing that comes close to native UI.
  • Also, building an app that requires no connection to the web has been really fun. It is so fast! I’d like to move forward by trying my best to keep HTTP request at zero or as low as possible.
  • The amount of information an iOS device knows at any given time is pretty amazing. It can know (with the user’s permission) where it is, what altitude it is at, which way it is pointing, how many times the person’s heartbeat that day, what it is looking at, etc. etc. Amazing to play with these features.
  • The Xcode IDE is really incredible to use. You may not remember a framework’s properties but you can just begin typing a reasonable word and expect that Xcode will figure out what you’re trying to accomplish. Also, if you happen to write older syntax because you’re following an out-of-date tutorial, it will automatically convert it to the most recent syntax.

Overall I’ve had a positive experience learning to build an iOS app on my own. Going from having an app in TestFlight to shipping an app feels like preparing to cross a desert on foot. But, I’m enjoying my experience so I’m going to trudge forward to do so.

I hope to ask for public beta testers of the app in a few weeks or a month.

Arguments aren’t parameters

Eevee on the names of things in programming languages:

Part of the problem here is that we’re not actually doing computer science. We’re doing programming, with a wide variety (hundreds!) of imperfect languages with different combinations of features and restrictions. There are only so many words to go around, so the same names get used for vaguely similar features across many languages, and native speakers naturally attach their mother tongue’s baggage to the jargon it uses. Someone who got started with JavaScript would have a very different idea of what a “class” is than someone who got started with Ruby. People come to Python or JavaScript and exclaim that they “don’t have real closures” because of a quirk of name binding.

I’m as guilty of spouting off inaccurate names of things as anyone. I catch myself using the generic term for the thing I’m talking about even if the language I’m referencing doesn’t support that feature. I use “method” a lot and I likely mean “member function”. I definitely say “argument” rather than “parameter”.

Fascinating piece as always from Evee. I’ve got a bunch of her posts saved to read later (as you can tell, this post is now 8 months old). I recommend subscribing to her site if you’re not already.

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.

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.