Tag: PHP

The eli4d Gazette – Issue 068: An Excellent PHP Benchmarks Site and the Magic of Instant.page

PHP Benchmarks Site

I came across this PHP Benchmark site which is cool in terms of framework, template engines, and PHP version comparisons. Of course, benchmarking is just one item of comparison, and there are many somewhat more important factors in choosing and learning a framework/template language like:

  1. How well do you know the language?
  2. How much have you studied the framework/template engine?
  3. How many projects have you deployed with a particular framework?

That last point is very critical. The more projects (personal, work, etc…) the more you know the framework, and the more quickly you can deploy an idea or a solution to a problem. Of course, the other side of knowing something well is tending to use it as a solution for everything (the Masslow’s hammer problem).

Note: I came across this benchmarking site while reading “Moving from Go to PHP again” via this Hacker News post.

Instant.page magic by preloading a page right before a user clicks it

I came across this page (https://instant.page/) through the fantastic Post Status club Slack workspace. I haven’t had a chance to play with this, but it seems pretty amazing that a 1 line addition to your HTML can potentially bring a significant increase in speed due to the link/hover behavior of users.

The technical details page provides information about this approach. Caveat emptor of course but it does seem pretty neat.

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

The eli4d Gazette – Issue 066: GitHub’s FREE private repos, Neat 2019 Tech Conferences, and the Amazingly Written “Leviathan Wakes”

GitHub announces unlimited free private repos

GitHub is the standard when it comes to Git based source control management.

Up to now, you could get a free account as long as your code was publicly viewable. While this has been great for public facing open source projects, it was problematic for those that wanted private source repositories (aka ‘repos’). A viable free private repo alternative has been Atlassian’s Bitbucket.

GitHub has recently announced unlimited free private repos. This change is great for anyone who wants to experiment around with some code without exposing their cruft out in public.

Some folks have lamented that now there will be many personal projects that will be locked away in private repos and that takes away valuable code that could be “out there.” While I understand this objection, I think it’s somewhat questionable. Every developer has the right to determine what is crappy code and what isn’t, and whether s/he is comfortable publishing it. After all, once something is public on the internet, it’s there forever.

Before GitHub’s change, Bitbucket was already used for private repos – so what exactly has changed? Am I to understand that Bitbucket’s free private repo feature was so secret that no developer ever used it? Or perhaps developers were too lazy to switch from GitHub to Bitbucket for personal projects?

Some interesting conferences from Delicious Brains

Delicious Brains is a WordPress company that develops high-end plug-ins for WordPress developers. They have a really nice development blog.

In a recent blog entry, they had a comprehensive listing of upcoming JavaScript, WordPress, CSS, UX, Tech and PHP conferences: https://deliciousbrains.com/php-javascript-wordpress-conferences-2019/

Just Finished Reading

I just finished reading Leviathan Wakes which is the first book from The Expanse Series. This was an amazingly well-written book covering the near future. In all honesty, no amount of words can express how well written this book is so I’ll pick three sentences that scratch the surface of this writing:

Here is a description of a space ship…can you see the image?

Three-quarters of a kilometer long, a quarter of a kilometer wide—roughly shaped like a fire hydrant—and mostly empty space inside, the Canterbury was a retooled colony transport.

What about these sentences?

Seven years in Earth’s navy, five years working in space with civilians, and he’d never gotten used to the long, thin, improbable bones of Belters. A childhood spent in gravity shaped the way he saw things forever.

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

The eli4d Gazette – Issue 054: Dependency and Package Managers in Python and PHP

Python Environment and Package Installation

I saw a recent XKCD comic that describes the current state of setting up a Python development environment:

Python Environment

The excellent Explain XKCD site covers the point of the cartoon. The issue is the (ongoing) difficult transition from Python 2.x to Python 3.x and the reality that there is no defacto package installation tool. The messiness of Python’s development environment deeply contrasts with the cleanliness and beauty of the actual language.

One interesting and significant effort in approaching the above issue can be found through the PyPi package manager. A great FLOSS Weekly episode had an interview with one of the maintainers of the new PyPi covering its pros and cons.

PHP’s Composer and Package System

In the PHP world – Packgist site is the definite destination for third-party PHP packages. In conjunction with these packages, Composer is the defacto package/dependency management tool. It’s more than a package manager because it focuses on managing packages on a per project basis.

At its core Composer focuses on dependency management and the secondary result is that it also does package management. One problem that arises is the usage of Composer as a pure package installer across a system rather than just a project. As Composer’s documentation states:

By default it does not install anything globally. Thus, it is a dependency manager. however support a “global” project for convenience via the global command.

Composer’s “global” command installs packages in a common central project and this, in turn, can cause major headaches with projects that have packages installed in different locations.

Pantheon’s blog describes this issue (and its solution) really well:

One of the most commonly documented ways for a PHP command line tool to be installed is via the composer global require command. This command is easy to document and easy to run, which explains its popularity. Unfortunately, this convenient function has a darker side that can cause some pretty big problems. The root of the problem is that Composer, by design, manages dependencies on a per-project basis; however, the global command installs everything into a common central project. The upshot of this is that two distinct projects that were never intended to be combined must suddenly share dependencies. In this configuration, it is all-too-common to encounter dependency conflicts that never would have been observed had these applications been installed independently.

The current solution to this is a Pantheon created tool called Cgr. The blog article provides details on its usage and when to use Composer global.

Note: many thanks to the folks on the Poststatus Slack for discussing Composer’s issues and pointing to Cgr.

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

Using the Boring / Old / Popular (BOP) criteria for server side software evaluation

Overview

Episode 14 of the “Under the Radar” podcast covered the specifics of how to best architect a back-end service for you mobile-app, web service, web application, and so on. It’s a follow-up to a previous episode (https://www.relay.fm/radar/13) about the Parse shutdown and the potentially high cost of external dependencies. The one part of this conversation that really caught my ear was around 09:15 and it contained the following interesting approach:

“What you want most of all when choosing server software – if you don’t want to be administering and tweaking your server constantly – what you want is old, boring, and popular. Those 3 things – old, boring, and popular. New and trendy does not always mean better.”

Marco and David emphasize that you should reserve the exciting technology for the customer facing side. Whether it’s your mobile app or a browser side JavaScript framework that will amaze your customers. The back-end of your application, the “infrastructure” should be technology that is boring, old, and popular (lets call it BOP since you can never have enough acronyms) because you want solid reliability in the same way that when you’re home you want a solid source of water and electricity. After all, usually the frontier of front end development is…the front 🙂 (of course this is a generalization for business-to-consumer applications).

A word of thanks

I’ve approached this by looking for numbers and meaning at github.com and libraries.io. Obviously non-github.com projects (like the Apache web server) cannot be looked at in this way because the direct stats aren’t there.

Special thanks goes out to:

  • Marco and David for the content of their podcast and the BOP idea/approach
  • Rachel Berry from GitHub for answering my questions about the best way to interpret GitHub statistics
  • Andrew Nesbitt from Libraries.io for answering my incessant questions about Libraries.io’s statistics

Note that I discovered libraries.io through the amazing Changelog podcast (episode 188). If you’re looking for a tool that will help you figure out your open source compliance (as well as many other things) – check out Libraries.io’s services (I would suggest that you listen to the Changelog podcast to get a clear understanding of Libraries.io’s value).

Lets break this down

If you’re new to this, the first question is where to begin?

I think the place to start is to find some sort of categories that are related to back-end technologies. After all, there’s no point to compare Linux (an operating system) to Ruby on Rails (a web framework).

Two sources that seem interesting in terms of such categories are:

GitHub’s showcases page

In terms of back-end technologies (i.e. server side software) that are shown on the showcases pages the following areas seem more relevant:

  • Web application frameworks
  • Programming languages
  • Open Source Operating Systems
  • Projects that power GitHub (i.e. seeing the components that run a huge enerprise like GitHub – some of these components will likely fit the BOP model; some of course will not fit this since GitHub can afford to hire devs for very niche and young projects)

Note: The image below is an aggregation of the 3 pages of this showcase and the “Search showcases” fields is great to finding a category for a specific project.

GitHub's showcases page

Libraries.io main page

Libraries.io has lots of different ways to look for projects. The keyword section at the bottom seems quite interesting.

Libraries.io main page

Boring, Old, Popular: What does ‘Old’ mean?

While I initially wanted to start with ‘Boring’ because BOP starts with it (and BOP is memorable), I realized that the better way was to start with the property that is easiest to figure out, or at least something that seemed easier.

What does ‘old’ mean in terms of software? Is 2 year old software ‘old’, or does 10 year old software count as ‘old’? (in the case of this post ‘software’ means ‘open source project’)

The definitive answer is “it depends” but that doesn’t help much. I think the better question is “is this piece of software ‘old’ within its category?” In the following examples, we’ll look at the web applications framework showcase on GitHub.

Boring, Old, Popular: What does 'Old' mean?

Rails is 12 years old…that’s definitely old – isn’t it?

Rails is 12 years old...that's definitely old - isn't it?

Express is 6 years old

Express is 6 years old

Laravel is 5 years old…so what gives?

Laravel is 5 years old...so what gives?

Meteor is 5 years old….but is that old?

Meteor is 5 years old....but is that old?

What about the age of the Internet?

Good lord – that depends on your definition. Is it starting from the 1950s when computers were more widely used by governments and universities?

If I’m going to pick a number – I’m going to use HTTP as my criteria so: 2016 – 1989 = 27 years.

What about the age of the Internet?

Damn it – what is ‘old’?

I was tempted to use log2 to help figure the numbers (because logarithms are COOL), but then I thought about what it means to be ‘old’ as an adult and used that to figure out ages of adolescence, young adulthood, middle age, and old age. Here’s an imperfect attempt at figuring this (I use percentage of LEB to help with range indication for age stages).

Note that I’m using Soulver for these calculations (the best-est ‘human’ usable spreadsheet program out there).

Damn it - what is 'old'?

So if I use the age of the Internet as 27

Umm…this is a bit of a chicken and egg thing in terms of current technology and the origin of technology.

So if I use the age of the Internet as 27

Lets make InternetLEB 16

I definitely feel that Rails is ‘old’. What if I take 16 as the InternetLEB. 2000 seems like the ‘right’ year for Web 1.5/2.0 – doesn’t it?

This makes more sense to me but you can picke whatever InternetLEB works for you. So here’s a criteria of judging the age of a project. Based on the Marco/David criteria – you would want a project that is in the middle-age to old-age area. That is the definition that I’m picking for the ‘Old’ part from the BOP criteria.

Lets make InternetLEB 16

Boring, Old, Popular: What does ‘Boring’ mean?

Stepping back for a second to the Under the Radar episode about this whole BOP criteria, the discussion centers around backend software. Software that resides on the server, software that is supposed to be rock steady so you don’t have to worry about your web site or web service falling down on its face on a frequent basis. So we’re talking ‘boring’ in this context, not ‘boring’ as in “uninteresting and tiresome; dull.”

Still, what’s a better definition in this context?

My definition for this is “software that has clarity in terms of usage and is used in many projects because of this clarity”. To me ‘clarity’ refers to a couple of things:

  • how it is used in the context of application/service (i.e. well defined use)
  • used by many others, which in turn leads to clarity in terms of direct documentation or indirect documentation (i.e. stack overflow answers that add up to common and clear usage practices)

Now in terms of hard numbers – I’m not sure how to define and discover ‘boring’ in terms of GitHub or libraries.io. The closest thing that I can think of is the “Dependent Repositories” number from Libraries.io’s SourceRank number (example shown for Rails). I was unclear about the difference between “Dependent Projects” and “Dependent Repositories” and I got the following clarification from Andrew Nesbitt:

*Dependent repos and dependent projects are two separate things, for dependent projects of a rubygem, it’s the number of other projects that list that as a dependencies, for rails there are ~7940 other rubygems that depend on it: *https://libraries.io/rubygems/rails/dependents

For dependent repos, it’s every Github repository that has rails listed as a dependency in it’s Gemfile or Gemfile.lock, which there are around 60,000: *https://libraries.io/rubygems/rails/dependent-repositories *

I asked Rachel Berry if there was anything equivalent on GitHub and there didn’t seem to be anything that was directly equivalent. She suggested the use of code search to provide a rough statistic. So something like https://github.com/search?utf8=%E2%9C%93&q=gem+rails+path%3A%2F&type=Code&ref=searchresults or https://github.com/search?utf8=%E2%9C%93&q=%22gem+rails+5%22+path%3A%2F&type=Code&ref=searchresults could provide a possible alternative. The problem with this approach is that you need to know how a dependency is included and then deal with the various variations in inclusion strings (besides other issues like different package managers for different software).

Overall, I don’t think there is any “hard” number that can easily capture the ‘boring’ criteria. I think that in this case ‘boring’ is really the result of looking at ‘old’ and ‘popular’. So instead of the BOP criteria it should perhaps be (B)OP or B/OP. Moving forward from this point – I’m going to go with (B)OP.

Boring, Old, Popular: What does 'Boring' mean?

Boring, Old, Popular: What does ‘Popular’ mean?

I left the “best” for last – POPULARITY. What the heck is ‘popular’ when it comes to the BOP criteria?

Is popularity based on GitHub stars?

How useful are GitHub stars in evaluating popularity? They seem somewhat transient and unreliable for this criteria.

Is popularity based on GitHub stars?

What about popularity based on GitHub forks?

Forks by their very nature are other people’s experimentation with a project. Of course there could be upstream contribution but how much of forks are actual contributions back to the project?

Forks seem like a way of learning and modifying a project’s code but I don’t think that they have anything to do with popularity.

What about popularity based on GitHub forks?

What about project members?

So the “Members” graph is a visual representation of the Forks number (i.e. “members” of the fork network). It’s another view of forks, and therefore its ‘popularity’ usefulness is questionable.

What about project members?

What about a project’s contributors as a reflection of popularity?

I think that this is similar to forks – specific people being interested in a project for their own reasons.

What about a project's contributors as a reflection of popularity?

Something that ‘trends’ is popular – isn’t it?

Something that is trending may reflect momentary popularity. But it is certainly in conflict with the ‘old’ and ‘boring’ criteria, so this is definitely not a good measure.

Something that 'trends' is popular - isn't it?

OK – I FOUND IT – I KNOW THE DEFINITION OF POPULAR!

Actually I don’t but I’ll take a run at it anyway.

I don’t know what’s popular or how to best evaluate popular in terms of the BOP criteria. Maybe it’s one of those I’ll know it when I see it things. Still, it doesn’t help anyone who is new to backend software infrastructure. The best thing that I can come with at this point is Libraries.io’s SourceRank number as a decent data point for popularity. Is it the best? Probably not. But I don’t see anything that’s better at this point.

Note: We need to keep in mind that log values are used in the creation of SourceRank so a difference of 2 between the SourceRank numbers of two projects could be quite significant

OK - I FOUND IT - I KNOW THE DEFINITION OF POPULAR!

(B)OP Comparison Example

So essentially – the (B)OP criteria boils down more to the O and P, since B falls under O or P – your choice.

  • Old = age based on the previously mentioned age/stage criteria using the year 2000 as a baseline
  • Popular = SourceRank at this point or using a GitHub source search if the project is unavailable on libraries.io

With the above in mind – lets compare Rails and Express.

The (B)OP criteria for Rails

So for Rails we’re looking at:

  • Old = 12 years with an age factor of %75; so its at middle-age about to hit old-age
  • Popular = SourceRank of 28

The (B)OP criteria for Rails

The (B)OP criteria for Express

So for Express we’re looking at:

  • Old = 6 years with an age factor of %44; so its at middle-age
  • Popular = SourceRank of 26

The (B)OP criteria for Express

Which to choose?

So all things being equal (discounting for things like experience in Ruby/JavaScript which could easily change the decision), the choice in this case would be Rails. This is due both the O and P factors. Granted, other comparisons might be much closer, and then it comes to preferences of programming language, educational interest in a particular project or technology, and time for experimentation and implementation.

Conclusion

So in summary – make your back-end server and services the best they could be by choosing the most (B)OPish (boring, old, and popular) technology when looking at the server side level of your technology stack. This advice would seem to contradict the “I want to develop on the latest and greatest technology”, but it is the best path to system administration sanity and it takes away nothing in terms of the fun part of your product and using the latest/greatest in there.

Some other resources that I came across

While researching and reflecting on this post I came across some resources that might be useful for those that are looking for ways to distinguish different projects (this is not limited to server side type of projects):

Some other resources that I came across

About this post

This post was written by @eli4d and it originally appeared on eli4d.com on March 10, 2016.

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

Summary

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 Overcast.fm 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)

Detail

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.

Conclusion

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