The eli4d Gazette – Issue 025

Issue 025: 2017-03-15

Tech Pick

Git is a version control system that most developers use. Additionally, most open source projects publish their source code repositories via Git (typically on GitHub). Consequently, it’s very useful to know Git. The funny part about Git is that initially, it’s easy to use, but any heavy usage can lead to a blackhole of frustration and concern (‘Am I doing this right or will I mess up my whole code base?’). I came across two great resources that you might find useful:

  • A very reasonably priced Git course called Getting Git. The developer (Jason McCreary) is pretty awesome and very giving regarding his knowledge and time. Here are two podcast episodes where Jason is interviewed (in case you want to know more about him):
  • If you’ve been interested in contributing to open source software but haven’t been sure how to do it, then you’ll find Matt Stauffer’s article to be very useful actionable.

Media Pick

I’m a sucker for Audible’s Daily Deal. This means I sometimes buy some audio books which are not in my wheel house (a good thing in terms of stepping out of my typical media consumption). I just finished a daily deal purchase – “Radical Acceptance” by Tara Brach. It was a stunningly good book about the actual implementation and use of Buddhism in daily life. The reader (Cassandra Campbell) was excellent, and I plan to re-listen to it at a future point with the intent of practice rather than just consumption.

Note: While this is not directly related – through my various audio book purchases I learned the following lesson: Never ever ever buy an audio book that is read by the author. 9 out of 10 times such a book ends up being a terrible disappointment. One such example is “Algorithms to Live By”. I have yet to be able to get through the book because of the author’s reading. It’s great content but terrible delivery.

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

The Laravel Podcast Episode 42 and the Meaning of …

I really enjoyed last week’s Laravel Podcast episode 42. Now since it is episode number 42 – I expected it to contain the answer to the ultimate question of development.

Now when you listen to the episode, you might think that the ultimate question that’s being answered is “which is the best object relational mapping approach/pattern – ActiveRecord pattern or the Data Mapper pattern?”

Or perhaps the ultimate question that’s being answered is “Should the ‘Single Responsibility Principle’ be violated when it comes to ORMs?”

Of course you need to listen to episode 42 to make your own decision. Perhaps it’s all ORM drama and dogma that is just a mystery wrapped in a Twinkie.

Personally, I think that the ultimate question is “how should you approach feature creation when it comes to software development?” And the answer is stated at the 46th minute of episode 42 (if only it was the 42nd minute…it would have been perfect…it’s time to repeat ‘serenity now’^100 and come to terms with this lack of symmetry). So what is the answer is:

“Don’t do it until you need it.”

Sounds simple – doesn’t it?

Laravel Podcast Episode 36 – Dev School – the unofficial/informal show notes


I really like the Laravel podcast. It’s a (typically) very short podcast covering both development and the Laravel framework. I like this podcast so much that I recommend it to my PHP students. It’s a nice informal conversation between seasoned PHP developers that covers the Laravel framework, PHP and other general development aspects.

The only down side of this show is that there aren’t any show notes (at least not for recent episodes). I found episode 36 to be really good in terms of pragmatic advice to those beginning to code. I think it will be really useful for my programming students which is why I decided to write a quick post providing my version of the show notes for this specific episode.

Things to note:

  • The episode is great up to time mark 41:40 (i.e. 41 minutes / 40 seconds) and then it deviates into a discussion about comfortable clothing. Feel free to skip this part. Of course if you want fashion hints from seasoned developers – then feel free to listen 🙂

  • The episode location is on the laravel podcast site. However, the linked time marks use since that site provides a web player to specific time marks and it is my podcast player of choice where I listened to this episode. If you have an iPhone you should definitely give Overcast a try – it’s fully featured and free. Of course if you like it – you should donate.

  • Should you believe anything these guys say? Well – you shouldn’t believe anyone. Take it with a grain of salt and see if it makes sense. I think the perspective of this episode is useful because of the following:

    • Taylor: super backend developer and creator of the Laravel framework; very down-to-earth
    • Jeffrey: implementer of Laravel for his business (Laracasts) that involves teaching so he he has an interesting perspective on the how-to-learn-programming side
    • Matt: started as a ‘designer’ and ended as a front-end developer that now has his own company (so both a developer and business owner perspective)


I’ve arranged these show notes based on new beginner developer questions and the relevant time marks. I’ve paraphrased the questions but you’ll hear the exact question that Matt asks when you listen to the specified time marks. The usual disclaimers apply.

If I want to be a crack Laravel developer and I’m a complete beginner – where would I start? (01:30)

Time mark: 01:30

An interesting discussion of how to get from being a newbie to becoming experienced in Laravel. But it applies to any interesting framework/language.

What should I build when I’m learning? (14:35)

Time mark: 14:35

A good discussion of whether your learning project(s) should be ‘real’ and whether toy projects are the way to go (short answer: yes).

Boot camps: are they worth it? (15:38)

Time mark: 15:38

This frequently comes up in my in-person class. Up to now I didn’t have a great answer but this part of the episode covers this really well both from a what-do-you-learn perspective and from the job search will-an-employer-hire-me perspective.

What are the quintessential books every backend developer should read? (20:52)

Time mark: 20:52

This part of the podcast covers many more books than what a backend developer would use. There’s some dead air in the podcast for this question when Jeffrey speaks. Here are the books that I deciphered (I will update this if I hear back from Taylor/Matt/Jeffrey via twitter for anything that I missed).

Are there any tricks/pitfalls that you have fallen into as you were learning? (30:41)

Time mark: 30:41

This addresses the Law of the instrument question.

Knowing what you know now is there any one thing you wish you would have known or done when you began to learn programming? (32:36)

Time mark: 32:36

A long time ago I heard the “knowing what you know now” question in a Brian Tracy audio book. It applies to lots of thing including programming.

The clothing question that you can safely skip: is there any piece of clothing that you would fight about if your spouse threw it away? (41:40)

Time mark: 41:40

Thinking of my ripped gray hoodie still makes me sad.


Hopefully you’ve found this useful. Send me a tweet if you did.

The Voice Behind the Code

I recently listened to The Changelog episode about a static site generator called Middleman (as an aside – The Changelog is an amazing podcast about all kinds of open source software – kudos to Adam Stacoviak). Now I’m not a user of Ruby (haven’t had time to play with Ruby nor Rails) but after listening to this episode I really want to try out Middleman and in fact I put it on my list of projects to play with when I have time.

Why? Because I liked how Thomas Reynold presented himself on The Changelog, I like his philosophy in developing and managing Middleman. It’s a side project that he’s been maintaining for a long time and he’s committed to maintaing it for a long time still. Furthermore, his technical decisions and evolution of Middleman shows me that he’s someone who’s willing to evolve his software rather than let it fade away in a morass of old crufty code.

My immediate reaction of putting Middleman on my project playlist made me consider my own approach for selecting software. I used to look at software based on popularity as measured by techie blogs and the latest fad. Somewhere along the line I changed my approach and how I purchase software. Somewhere along the line, I started paying attention to the the voice behind the code.

These days – when I come across an interesting product – I start reading the blog of the developer (or company), and then I move onto any podcasts that the developer has participated in. It’s an oddly personal path to a product. I suppose that marketeers will call it ‘personalization’ or some such thing.

When did this start for me? When did I change from a blind purchaser of software to a more reflective one? (I think this is more applicable to Mac software purchases than iOS products where I’ve bought lots of crap before stopping my purchases for the most part)

I think it started with the Build and Analyze (B&A) podcast where I heard Marco Arment talk about software development. I found out about B&A from a Merlin Mann podcast called Back to Work.

I bought Marco’s Instapaper app because of B&A. Here was an opinionated developer that wasn’t afraid to tell why he did or didn’t do certain things when it came to Instapaper. I liked the guy’s honesty, hard headedness and general East Coast demeanor. Marco sold Instapaper in 2013 and I thought that Instapaper was doomed to take a long slow nosedive into oblivion. But I was wrong because Marco entrusted his software baby to a great steward for his product.

He moved on from B&A to the Accidental Tech Podcast. He also created The Magazine but I didn’t buy it because it was not my cup-of-tea as a product (Apple’s Newstand never seemed right to me so I never bought anything in it).

He recently created a fantastic podcast client which I’ve been enjoying since day one of its launch. Overcast embodies Marco’s sensibilities and his choices fit the checkboxes that I have for a podcast client.

It’s funny how all of this started because of a podcast and listening to some anonymous guy passionately talk about his software and why he made certain choices when designing that software.

I have yet to be disappointed by a product purchase that is based on the voice behind the code. I’m not sure if this is a great approach to purchasing software but it works for me.

Voices that I’ve liked:

Amazon Web Services Lesson – S3 Bucket Names are Universal so get your domain named S3 bucket before someone else does

I recently subscribed to Nicholas Zakas’s excellent newsletter and came across a shocking realization about Amazon’s S3 service: all S3 bucket names are universal. Let me explain what this means.

It all started with wanting a static image server for my blog

A few weeks ago I wanted to host all images for this site on Why? Well I wanted to be able to easily move my blog without worrying about static assets. I also wanted to explore an AWS service such as S3.

I finally got it to work after beating my head against some security policy issues (this had more to do with me than Amazon but this is for another post). One of the key points that I learned when doing this is that the simplest approach to create an S3 based static site requires naming the S3 bucket with the name of the domain.

But then I read the following from Nicolas Zakas’s newsletter


But then I read the following from Nicolas Zakas's newsletter

OMG – what?

image attribution:

OMG - what?

So what does this mean?

It means that if you have any intention of ever having a static S3 based website, then you should create the S3 buckets with the various permutation of your domain’s names before someone else does (so,,, etc…). This is worth doing even if you don’t use those S3 buckets.

Keep in mind that you’re not locked out of using any other S3 buckets for your domains. But you have to deal with some unnecessary hoops.

So what does this mean?


Many thanks to Nicolas Zakas for documenting his experience with S3.

Rough Notes: Photoshop Basics Class

Note: I don’t have photoshop on my machine (yet) so I couldn’t verify all of my notes. As usual the typical disclaimers apply to this information.


I had the opportunity to go to a Photoshop basics course. The class was taught by Robert Williams from

Photoshop is one of the few programs which I’ve struggled in getting the ‘mental model’ of the program. This is yet another attempt to focus on the some core principles of usage.


  • !bp = best practice
  • !pt = pro-tip in terms of photography
  • Mac keyboard control keys:
    • OPT = the alt/option key
    • CMD = command key (aka the clover key)
    • CTRL = control key

The Notes

Book for class (not used during class but given as a reference)

“Photoshop CS 6” – Visual Quickstart Guide
by Elaine Weinmann and Peter Lourekas

I flipped through it and it has lots of visuals (which I suppose is not surprising considering it’s a visual quickstart). I can’t tell whether it would help with the mental model understanding of the software.

Mental model

  • Related tool buttons are purposefully next to each other
  • Your best friends that make you play Photoshop like a piano:
    • Zoom tool via OPT key and mouse scroll-wheel
    • Hand tool via spacebar and mouse movement

Crucial Tools and Techniques

  • Zoom in/out shortcuts:
    • allows you to zoom in/out wherever mouse pointer is at
    • You should use OPT key and scroll wheel of mouse (for touch pad it will be swipe)
    • Keyboard shortcut: CMD +/- to zoom in/out
  • Hand tool shortcut
    • allows you to move around any part of your image
    • use space bar and mouse to quickly switch to move around the
  • Use the square brackets ( [ or ] ) to increase/decrease brush head on whatever tool that has such a head

  • Saving content

    • Get in habit of using CMD-s all of the time because there’s no auto-save (unlike In-Design for example)
    • File names and SEO:
      • Files with dashes are better because search engines will read content in terms file names and remove dashes and use the words for SEO (good name example: Monarch-Butterfly-ADJ.psd)
      • Underscores are not good word separators because they are removed and all words are squashed together into one word by search spiders
  • work in layers: save original; helps preserve stages – otherwise you’re dealing with permanent changes
    • !bp: Always look to the right and check what layer you are on before doing any work
    • Each layer is its own thing (not an additive mask though you could choose to do that); think of layers as panes of glass so you could scrape the top piece of glass so you could see the layers underneath it
    • Drag background layer to post-it note icon at bottom to create a new layer (???todo: check on photoshop???)
    • !bp habit: make sure you’re in the correct layer; layer you want to adjust is highlighted
    • !bp: Name your layers. Once you start having lots of layers it gets very confusing very quickly. To rename a layer just slowly click twice with left mouse button on the name of the layer. Lots of layers will get out of hand without naming
    • To make all other layers disappear so you can focus on one:
      • Get ready to click on the eyeball of layer you want
      • Press OPT key and then click on eyeball with mouse
    • Another way to figure out a particular layer is to use the move tool to distinguish (so you can name it)
  • History:
    • Records 15 steps
    • New timeline begins when you select at a particular point and start working on a layer


  • Marquee
    • Can only affect stuff inside
    • Selection menu has to do with marquee tools
    • Quick-selection tool
      • OPT key: de-select (so you’re highlighting areas you want to de-select)
      • Dynamic menu at the top: can increase/decrease of brush (i.e. circle); shortcut: [ or ]
    • When you do a complex selection make sure to save it via:
      Selection > Save Selection (to save all that effort); this is stored in the PSD file
    • Getting the non-selected space: Select > Inverse (now the background of the butterfly is used); so as a !bp select the smaller/easier thing and then use inverse to get the thing that you want (if applicable)
  • Color play with selection:
    • Image > Adjustments >
      • hue/saturation: allows you to play with colors of the selection
      • Levels: histogram (right arrow – what’s considered white; leftmost arrow what’s considered black; mid-arrow: mid-range)
      • The Histogram can help with FAST adjustment of photos in terms of light color, medium colors and darks; this helps sharpen things
      • Always work on the leftmost arrow first, then the right most, and then adjust the center arrow by eye (typically making the picture more high contrast for print)
    • Filter > play with these
      • !pt: Recommended blur that pro photographers use: Filter > Blur > Gaussian (0-3)
      • less is more with adjustments
  • Rulers:
    • Very useful for creating guidelines
    • CMD-R to access, or View > Rulers
    • To change default ruler type (i.e. inches versus pixels):
      Photoshop > Preferences > Rulers

    • Guidelines / guides:

      • left click inside ruler and drag out to create a guide
      • Another way: View > New guide: you can specify exact pixels
      • Hide guides via menu or CMD-;
  • Edit menu >
    • Transform > Scale (hold shift from corners to scale rather than distort)
      • When you’re in bounding box you need to hit return key to come out of it (otherwise – everything is grayed out)
      • For web you can scale without pixelation but not good for print
  • Image menu >
    • Canvas Size: to change size of image
  • Move tool: allows you to move layer around (very common use – shortcut is letter v)

  • Rectangle tool

    • Click on the layer to get selection of colors and eye dropper (!pt: select another color from image rather than some color from swatch in order to make it cohesive); this is in reference to putting a rectangle to put lettering on
  • Type tool:
    • the ‘T’ icon on toolbar
    • notice dynamic menu at the top
  • Masking an Image (!pt)
    • Great technique to show-through a particular shape
    • Make a box that will hold the image; anything outside of it will be invisible
    • Place your intended image above image mask
    • Use: Layer > Clipping mask
    • You can move image separately from object underneath (this allows you to easily re-crop)
    • This is nice non-permenanet change for the image you are dealing with

Odds and Ends

  • Note that for an image like logo instead of loading the jpeg/png and copy/paste you could do: File > Place but this creates a smart object which is very different than an image; see book for more info

  • If you see a “maximize compatibility”, then hit OK.

  • !pt: the more subtle the transition; the bigger the brush head that you want

  • actions: helps you process photos (aka batch processing in bridge); see book

  • !bp: separate photos into their own layers so you can have finer control for things like lightning; also makes it easier to manipulate the elements of a composite

  • Not photoshop related (besides the huge psd files that it creates) but to transfer big files the instructor recommended:

  • For web images – use the File > Save for web: you can control size of file for jpeg/png via quality option

  • Suggested resources: instructor heartily recommended courses

  • Use the / key to lock a layer (though it seems to do a ‘partial’ lock and there is no obvious way to do a readonly type of lock; the instructor indicated that has a great explanation of layer locks)

Updates to this post