The eli4d Gazette – Issue 036

Tech Pick

I came across this interesting question about choosing a development stack.

The Question:

When building a new web app, project, website, how do you choose your development stack? Nowadays there are hundreds of ways one could go about building the same project.

I am a entry level software developer wanting to start a side web project, but I feel stuck in analysis paralysis. I don’t mind trying to learn new languages either. Any thoughts or comments are appreciated! Thanks, guys!

I completely identify with the analysis paralysis issue. There’s just so much interesting technology out there (whether a tech stack or programming language).

There’s an answer (further down the page) that mentions a neat article – The Boring Stack – The Best Way To Build Interesting Things. It’s a worthwhile article that gets to the heart of the question.

The top answer given asks the questioner to distinguish between the desire to learn something new versus the desire to start a business that needs a development stack. This is a very thoughtful criteria (emphasis mine):

If your goal is to learn a new language [or a new development stack], that’s fine – pick something that looks interesting, or that furthers your career development. As a web developer: rails, python + django or node are all decent choices with wide adoption, and you should probably know at least one of them.

If your goal is to start a business, pick a tech stack that you know and that lets you move fast with safety. Learning new tech is not the goal here.

Media Pick

I’ve mentioned the Functional Geekery podcast previously. I like how it completely focuses on functional programming. I found episode 106 to be good in following the interviewee’s (Reid Evans) journey into functional programming. The show notes also had some interesting functional JavaScript resources including Reid’s channel on YouTube.


Thoughts? Feedback? Let me know: @eli4d on Twitter


Advertisements

The eli4d Gazette – Issue 035

Tech Pick

I came across an interesting article covering a comparison of PHP frameworks. The comments at the bottom of the article are also quite interesting, to say the least.

Personally, I’ve chosen Laravel as my go-to framework. I’m learning it by applying it to a personal project. It is well covered through excellent documentation, great video tutorials, and a good book. I’ve written about Laravel on my blog quite frequently.

Media Pick

This is tangentially related to media through the MP3 format.

Recently I bought a Love & Logic audio book (great approach for new and experienced parents). My main listening program is the Overcast podcast player. It has great fast playback options. The audio book I got had 10 small MP3 files and the Overcast site allows for individual uploads of files which is a pain. So I figured it would be easier to merge all of these MP3 files into one large MP3 file that I could upload into Overcast.

I tried two approaches that didn’t work: Toast Titanium and using the ‘cat’ command. Looking around further I came across a StackOverflow thread that mentioned the ‘cat’ approach and a utility that did work. The utility was: MP3Cat.

It’s a Go program that works on Mac, Windows, and Linux. It works as follows on the command line:

./mp3cat -o merged.mp3 file1.mp3 file2.mp3 file3.mp3

It works amazingly well, and I highly^100 recommend it.

Drobo Blues (part 3)

On my fourth return I was finally able to exchange the Drobo 5N for a Drobo 5D. The three 5N units that I tried never worked on my network and Drobo support were unable to help me. The 5D is a massive external hard disk with lots of redundancy, so it needs to be connected to a computer. It is also simpler than the 5N and far from being a NAS.

What I’ve learned (and this, of course, is my extremely narrow experience/opinion):

  1. Drobo support is great (for the 5D unit I got extra Drobo Care for free). They tried to help me, but there’s not much they could do with consistently bad Drobo 5N hardware.
  2. I can never trust Drobo’s NAS systems (apparently the “Drobo Difference” does not apply to me). Maybe my case is a complete fluke, but the brand new unit I bought and two additional units did not work whatsoever on my network. If/when I get around to another NAS purchase attempt, I will try out Synology and/or Qnap.

Thoughts? Feedback? Let me know: @eli4d on Twitter


The eli4d Gazette – Issue 034

Tech Pick

This is somewhat of an ‘anti-pick’.

When it comes to technical book publishers, O’Reilly used to be at the top of my list. Unfortunately, this is not the case anymore. I wrote a post about O’Reilly’s abandonment of DRM Free technical books and using other alternatives.

Media Pick

While listening to a recent Security Now podcast, I heard Steve Gibson rave about Ryk Brown’s Frontier’s Saga series. I found that it was available via the Kindle Owner’s Lending Library so I started reading book #1…and I was hooked. I’m on book #6, and it continues to be fantastic science fiction series. I highly recommend this series to any fan of space opera type of science fiction. So if you like Star Trek you’re very likely to really (really) like this series.

Drobo Blues

My Drobo 5N saga/sadness continues. I got a replacement, and it still doesn’t work. I’m in another round of back/forth with Drobo support. Even if I get it working, I’m not sure how much faith/trust I can have in their NAS.

Knowing what I know now I would try Synology rather than Drobo. Synology’s SHR technology seems quite comparable to Drobo’s Beyondraid, so Drobo’s previous multi-size hard disk advantage (i.e. being able to use different sized hard disks) seems moot.


Thoughts? Feedback? Let me know: @eli4d on Twitter


The eli4d Gazette – Issue 033

Tech Pick

I’ve been making slow glacial progress (due to everything else in my life) in learning Laravel while working on a side project. As part of this, I’ve been listening to lots of PHP and Laravel podcasts. Twenty Percent Time is a new-ish podcast where two developers from Tighten (Caleb Porzio and Daniel Coulbourne) discuss various programming topics that typically revolve around Laravel. On the latest episode, Caleb verbalized something that I’ve fundamentally believed in for a long time though I didn’t have the words for it. Here is what he said:

“You can be an unbelievable super successful super smart great Laravel developer and know nothing but the Laravel docs and use nothing but the built-in Laravel things. You don’t have to learn design patterns…you don’t have to learn the internals of how everything works…it’s kind of crazy, but that is the path to mastery. The path to mastery is knowing how to use the tools really well, just using the tools that are in the docs.

Beyond learning Laravel, I think that Caleb’s quote is significant for those of us that get super-involved in learning about the latest ‘shiny’ thing, rather than learn a few tools well to create something.

Media Pick

I can’t recall a time in my life when political polarization was greater than it is now. I’ve recently come across a constructive podcast (“What Trump Can Teach Us About Con Law”) covering our president in the context of constitutional law. It fits my ‘learn by example’ style, and it is a fantastic study of our country’s constitution.

Random

  • I bought a Drobo 5N last November during a black Friday sale. I didn’t get to unbox it until a month ago (lesson learned – test hardware as soon as possible; I knew this, but life has been busy). Within a few days, I found that my Drobo was a dud. Fortunately, Drobo’s diagnostics in combination with Drobo support has been excellent so far, and I have a replacement coming. Hopefully, I’ll experience the Drobo difference soon :-).
  • I’ve had lots of emails with OmniFocus support about the last corruption. This infrequent/intermittent bug got even escalated to an OmniFocus engineer. Their support has continued to be stellar.

Thoughts? Feedback? Let me know: @eli4d on Twitter


The eli4d Gazette – Issue 032

Tech Pick

I’ve had Python on my brain lately due to heavy duty preparation for my upcoming online Python course. So coming across Instagram’s Python technology stack was interesting. The article begins with:

Each day, over 95 million photos and videos are shared on Instagram. The unstoppable photo-centric social media platform has over 600 million registered users — 400 million of whom are active every day. Talk about operating at scale: Instagram kills it at levels most companies can barely even dream about.

Even more impressive, though, is the fact that Instagram serves this incredible amount of traffic, reliably and steadily so, by running Python (with a little help from Django) under the hood. Yes, that Python — the easy to learn, jack-of-all-trades general purpose programming language. The one everybody in the industry dismisses as, “Yeah, Python is great in so many ways, too bad it’s not really scalable.”

I thought that this was a great example to mention to my students – “well if Instagram uses Python at their scale, Python must be a good thing to learn.” And yet this didn’t sit right with me, and I remembered reading an excellent article that clarified my unease: “You Are Not Google”.

Python is a great language for many reasons (easy to learn, lots of built in libraries, great scientific/numeric support (SciPy, Pandas, iPython, NumPy), etc..) but Instagram’s use of it is not one of them. I’m not Instagram, and it’s very likely the case that you aren’t either.

Media Pick

I’ve had “American Gods”aal on my Kindle for what seems like forever. It was recommended by a friend back in 2004 and I got the Kindle version on sale a few months ago (via Bookbub).

Where to begin? The story is like a fractal of a pick-up stick game. You think “really Neal – a pick-up stick game?” And there’s Gaiman laughing manically. So you play the game and read the book 1 bit at a time…and just when you think you understand, repeating themes and whispers of previous chapters slap you across the face.

My Kindle highlights are filled with too many sentences from this book, and I can hardly pick a favorite. Here’s an example:

“The house smelled musty and damp, and a little sweet, as if it were haunted by the ghosts of long-dead cookies.”

aal = Amazon affiliate link

Random

I’m a big OmniFocus, but recent (XML) corruptions have been worrisome (on the positive side OmniFocus support is top notch). One database corruption happened in March, and another just happened about a week ago. My favorite data format is plain text. But I haven’t come across a plain text task management system that implements GTD and spans mobile and Mac OS X as seamlessly as OmniFocus.


Thoughts? Feedback? Let me know: @eli4d on Twitter


The eli4d Gazette – Issue 031

Tech Pick

Apple’s Worldwide Developer Conference is currently running in San Jose. Two interesting points from Monday’s keynote:

For those looking for a summary of the keynote:

Media Pick

I really enjoy the Imaginary Worlds podcast but the latest episode (Do the Voice) was really different. It was an episode that came from The Truth Podcast. The Truth podcast is about:

THE TRUTH makes movies for your ears: short stories that are sometimes dark, sometimes funny, and always intriguing. Each story is different, and usually 10 to 20 minutes long. We take you to unexpected places using only sound. For best results, use headphones!

I’ve started listening to it, and it’s quite a nice short audio trip that is weirdly worthed.


Thoughts? Feedback? Let me know: @eli4d on Twitter


The eli4d Gazette – Issue 030


Issue 030: 2017-05-24

Tech Pick

Last week an article sparked quite a bit of (justifiable) backlash against a SaaS company called Firebase. While Firebase did eventually respond to Home Automation’s protest about a %7,000 cost increase, this incident serves as an important reminder of the dangers of tying one’s business to any SaaS provider.

A few points from the article best summarize these dangers:

  1. They changed how they report their bandwidth usage, increasing our bill by 7,000% without any change to our actual usage. After years of using the service.
  2. No warning or message was sent out that this was being done — we only got notified once they were planning to shut down our app completely.
  3. Their profiling tools do not show the increased usage. You can only see it by looking at your massively increased bill.

So please, I beg of you…learn from our embarrassing and now dooming mistake:

  • Always build your architecture in a way that will avoid becoming trapped into a specific service. Build your application in a way that swapping one service for another is as simple as possible.
  • Always keep in mind that the services you use can change at any moment and put you in a situation where you don’t have options if you aren’t careful.
  • Whenever possible, rely on your own infrastructure. The SaaS model seems attractive to both Startups and Service Providers…. but in the end, its the Startup that gets bitten by it and the providers that make the real money.
  • Always heavily consider open source alternatives (something which didn’t exist for Firebase at the time but now alternatives like Horizon and Backendless exist, for example).

Media Pick

The Changelog podcast had an excellent episode covering the origin and usage of Kubernetes. I notated the interesting spots of this episode.


Thoughts? Feedback? Let me know: @eli4d on Twitter