We’ve seen quite a few scratch built lathes here at Hackaday, but none quite like the handcrafted pole lathe put together by [Jon Townsend] and his band of Merry Men as part of their effort to build a period-accurate 18th century log cabin homestead. With the exception of a few metal spikes here and there, everything is made out of lumber harvested from the forest around them.
The lathe is designed to be a permanent structure on the homestead, with two poles driven into the ground to serve as legs. Two rails, made of a split log, are then mounted between them. The movable components of the lathe, known as “puppets” in the parlance of the day, are cut so they fit tightly between the rails but can still be moved back and forth depending on the size of the work piece. With two metal spikes serving as a spindle, the log to be turned down is inserted between the puppets, and wedges are used to lock everything in place.
So that’s the easy part. But how do you spin it? The operator uses a foot pedal attached to a piece of rope that’s been wound around the log and attached to a slender pole cantilevered out over the lathe. By adjusting the length and angle of this pole, the user can set the amount of force it takes to depress the pedal. When the pedal is pushed down the log will spin one way, and when the pole pulls the pedal back up, it will spin the other.
Since the tools only cut in one direction, the user has to keep letting the pressure off when the log spins back around. The fact that the work piece isn’t continuously rotating in the same direction makes this very slow going, but of course, everything was just a bit slower back in the 18th century.
Let’s face it, those touchpads on laptops are awful, and were never meant to be the primary mouse for all-day use. Not that external mice are much better on your shoulder and neck in the long term — especially if you’re reaching past a 10-key and back to use it. So what’s the answer? What does a comfortable, portable mousing solution look like? Is such a thing even possible?
[Matias N.] has an idea: make the mouse an extension of your hand. The idea is that by wearing a battery-powered Bluetooth pointer on your thumb or index finger, you have a seamless back and forth transition with less overall stress. The trackpad includes a button that would be used to cover left clicks. To make it a full mouse, [Matias] plans to have extra buttons for right click and middle click, and a joystick for scrolling.
[Matias] started designing thumbMouse with a Blackberry 9900 trackball module in mind, but found it was way too slow for modern mousing needs. Turns out the trackpad module is much better suited: it’s a lot more responsive, and the movement is surprisingly sensitive.
At some point, you simply run out of processing power. Admittedly, that point keeps getting further and further away, but you can still get there. If you run out of CPU time, the answer might be to add more CPUs. However, sometimes there are other bottlenecks like memory or disk space. However, it is also likely that you have access to multiple computers. Who doesn’t have a few Raspberry Pis sitting around their network? Or maybe a server in the basement? Or even some remote servers “in the cloud.” GNU Parallel is a tool that lets you spread work across multiple tasks either locally to remote machines. In some ways, it is simple, since it looks sort of like xargs but with parallel execution. On the other hand, it has myriad options and configurations that can make it a little daunting to use.
About xargs
In case you don’t use xargs, it is a very simple program that among other things lets you do something with a list of files. For example, suppose we want to search all C source files for the string “hackaday” using grep. You could write:
find . -name ‘*.[ch]’ | xargs grep -i hackaday
Here, xargs grabs an input line, calls grep and after grep completes, it repeats the process until it runs out of input lines. (Note: handling files with spaces is a bit tricky. Using -d ‘\n’ might help, although not all versions of xarg support it.)
In the simplest case, Parallel does the same thing, but it can execute grep — or whatever you are using — multiple times at once. On a local machine, this allows you to use multiple CPUs to improve timing. However, you can also spread the work among different machines that have passwordless ssh logins.
Demos
The author of GNU Parallel has a multipart video demonstration of the system. You can see the first part, below. The tutorial is also very good, and clears up a number of details that might not be obvious from the man page.
Just for my own amusement, I took a directory with some large mp4 files in it and used both xargs and parallel to gzip each file. I know, I know. The files are already compressed, so gzip isn’t going to do much. But I just wanted some large task to time. Here are the results:
[:~/Videos/movies] $ time find *.mp4 | xargs -d '\n' gzip
real 6m10.796s
user 2m52.828s
sys 0m9.718s
[:~/Videos/movies] $ time find *.mp4 | parallel --jobs 8 -d '\n' gzip
real 5m25.050s
user 2m56.676s
sys 0m7.732s
Admittedly, this wasn’t very scientific, and saving about 45 seconds isn’t a tremendous gain, but still. I picked eight jobs because I have an eight-core processor. You might vary that setting depending on what else you’re doing at the time.
Remote
If you want to use remote computers to process data, you need to have passwordless ssh remote access to the other computer (or computers). Of course, chances are the remote computer won’t have the same files and resources, so it makes sense that — by default — your commands only run on the remote server. You can provide a comma-separated list of servers, and if you use the server name of “:” (just a colon), you’ll include your local machine in handling jobs.
This might be very useful if you have a mildly underpowered computer that needs help doing something. For example, we could imagine a Raspberry Pi-based 3D printer asking a remote host to slice a bunch of models in parallel. Even if you think you don’t have any computational heavy lifting, Parallel can do things like process files from a tar archive as they are unpacked without waiting for the rest of the files. It can distribute grep‘s work across your CPUs or cores.
Honestly, it would take a lot to explain each feature in detail, but I hope this has encouraged you to read more about GNU Parallel. Between the videos and the tutorial, you should get a good idea of some of the things you could do with this powerful tool.
If you’ve got a few self-designed PCBs under your belt, you probably know the pain of missing some little detail and having to break out the bodge wires to fix it. So we feel for [Arsenio Dev], who placed an SD card slot next to an SoC, only to find that it was the wrong way round. Rather than tossing it in the bin, he decided to employ a particularly crafty set of bodge wires that curve over the board and connect to an SD card adapter on the other side.
Our attention was taken by the board itself, he’s posted little information about it and taken pains to conceal one of the pieces of text on it. Since it has an Octavo Systems BeagleBone-on-chip, a slot for a cellular modem, and a connector marked “CONNECT AERONET HERE” which we are guessing refers to the Aeronet sun photometry network, we’re guessing it might be a controller for remotely-sited nodes for that system. Either way it’s enough to have us intrigued, and we wish him every success with the next spin.
Junk Mail has conducted a second survey regarding the importance of online presence for your business during lockdown and beyond.
The results will help businesses and us make the marketing-focused changes required to stay ahead of the curve.
View the results below.
1. Has COVID-19 made having an online presence more important than before?
2. Have you increased or decreased your online advertising during lockdown?
3. How big is the current online presence of your business?
4. Do you have your own website?
5. Did you know you can get a FREE website through Junk Mail?
6. On which of the following channels does your business have an online presence?
7. Which of the following advertising options provided by Junk Mail do you use to improve your online presence?
8. What is the nature of your business
Survey Summary:
It’s clear that the majority of businesses agree that online presence is now more important than ever before although fewer businesses took the step of actually increasing their online advertising efforts.
Based on the above results, businesses mainly use Facebook, online marketplaces, WhatsApp, and Google as their main channels of advertising.
The majority of responders said that their online presence is currently small to average.
All clients with bookings from before the lockdown will be
contacted shortly to schedule appointments in the upcoming weeks.
Please note the new protocols for your appointment:
– Please come alone. No friends or family will be allowed into the studio with you.
– Sanitize your hands upon entering.
– A face mask and gloves will be provided. Please wear these
throughout your time in the studio.
– Please reschedule your appointment if you feel unwell or
have been in contact with anyone who may have Covid-19.
Thank you for your patience and continued support over the last few months. We can assure you that we have gone the extra mile to maintain the strictest level of hygiene to provide you with a safe and clean tattoo experience.
If you’ve got a few self-designed PCBs under your belt, you probably know the pain of missing some little detail and having to break out the bodge wires to fix it. So we feel for [Arsenio Dev], who placed an SD card slot next to an SoC, only to find that it was the wrong way round. Rather than tossing it in the bin, he decided to employ a particularly crafty set of bodge wires that curve over the board and connect to an SD card adapter on the other side.
Our attention was taken by the board itself, he’s posted little information about it and taken pains to conceal one of the pieces of text on it. Since it has an Octavo Systems BeagleBone-on-chip, a slot for a cellular modem, and a connector marked “CONNECT AERONET HERE” which we are guessing refers to the Aeronet sun photometry network, we’re guessing it might be a controller for remotely-sited nodes for that system. Either way it’s enough to have us intrigued, and we wish him every success with the next spin.
This morning the Open Source Hardware Association (OSHWA) announced a resolution for changing the way SPI (Serial Peripheral Interface) pins are labelled on hardware and in datasheets. The protocol originally included MOSI/MISO references that stand for “Master Out, Slave In” and “Master In, Slave Out”. Some companies and individuals have stopped using these terms over the years, but an effort is being taken up to affect widespread change, lead by Nathan Seidle of Sparkfun.
The new language for SPI pin labeling recommends the use of SDO/SDI (Serial Data Out/In) for single-role hardware, and COPI/CIPO for “Controller Out, Peripheral In” and “Controller In, Peripheral Out” for devices that can be either the controller or the peripheral. The change also updates the “SS” (Slave Select) pin to use “CS” (Chip Select).
SPI is widely used in embedded system design and appears in a huge range of devices, with the pin labels published numerous times in everything from datasheets and application notes to written and video tutorials posted online. Changing the labels removes unnecessary references to slavery without affecting the technology itself. This move makes embedded engineering more inclusive, an ideal that’s easy to get behind.
The Technology Itself
Even though the terminology needs an update, the approach to how SPI data lines are designated is one of the best of all protocols because the *O*I/*I*O format stays the same even when the device changes. This is easiest to understand when thinking about a microcontroller that can act as either the “Controller” or “Peripheral”. A controller will always send out its data on the COPI line (controller out) and receive data back on the CIPO (controller in). Now, the same device acting in the peripheral role retains the exact same pin labels. It just begins listening on the COPI line (peripheral in) and sending on the CIPO line (peripheral out). Under this naming scheme, the controller is always the device that controls the clock.
The SDI/SDO labels have most commonly appeared on devices that lack the ability to serve as an SPI controller (think sensors or LCD screens). But here’s the problem, when you have three or more chips in a design, which SDI lines get connected to SDO lines? Even with two chips, if one port is called SDI and the other is called SDO, what name do you assign to the wire? It’s the UART RX/TX problem all over again.
Retaining the COPI/CIPO paradigm, the problem is answered without any knowledge at all of function: all COPI lines should be connected to one another, as should all CIPO lines. Brilliant.
We Can All Decide to Make This Change
SPI is a de facto standard which Motorola published starting back in the 1980s. It’s simple and it works well, becoming one of the two most widely used chip to chip communication protocols along with I2C. But it’s not governed by a ruling body. That means, to change the pin names, all it takes is for people to decide we should change them. That’s what’s happening here.
With hardware manufacturers like Sparkfun and Adafruit, and the Open Source Hardware Association adopting the SDO/SDI and COPI/CIPO labels, the effort gets a jump start. I encourage you to make the changes in your own schematics, software, and documentation.
The hardware world isn’t the only place removing references to slavery from design specs. The OpenZFS project changed references to “slave” in the code base to “dependent” which was also abbreviated as “dep” for variable names. An article in Ars Technica published on the OpenZFS change also references a paper published by the Internet Engineering Task Force (IETF) standards organization recommending a shift away from oppressive language being included in defined standards.
The history of slavery is a dark and disturbing one, and its casual inclusion in engineering can be hurtful. In this time of introspection sparked by massive protests over racial inequality, systemic racism, and violence within law enforcement, this is one small but meaningful change the hardware world should choose to adopt. And one that I wish had been adopted long ago.
In June, 1995, Rasmus Lerdorf made an announcement on a Usenet group. You can still read it.
Announcing the Personal Home Page Tools (PHP Tools) version 1.0.
These tools are a set of small tight cgi binaries written in C.
Today, twenty five years on, PHP is about as ubiquitous as it could possibly have become. I’d be willing to bet that for the majority of readers of this article, their first forays into web programming involved PHP.
But no matter what rich history and wide userbase PHP holds, that’s no justification for its use in a landscape that is rapidly evolving. Whilst PHP will inevitably be around for years to come in existing applications, does it have a future in new sites?
Before we look to the future, we must first investigate how PHP has evolved in the past.
The Beginnings
Rasmus Lerdorf initially created PHP as a way to track users who visited his online CV. Once the source code had been released and the codebase had been re-written from scratch a sizeable number of times, PHP was enjoying some popularity, reportedly being installed on 1% of all domains by 1998. At this point, the language looked nothing like we know today. It was entirely written within <!-- html comments -->, with syntax noticeably different to modern versions.
Enter Zeev Suraski and Andi Gutmans, who were using PHP to try to build a business but found it lacking in features. Collaborating with Rasmus, PHP was once again re-written and released as PHP 3.0. Now we’re getting somewhere, with PHP 3 installed on an estimated 10% of domains at the time. This is also the point where the meaning of PHP changed from Personal Home Page to everyone’s favorite recursive acronym, “PHP: Hypertext Preprocessor”. This version and period is generally seen as the time in which PHP cemented its future status. Between PHP 3 and 4, phpMyAdmin was created, Zeev and Andi mashed their names together and founded the PHP services company Zend, and the venerable elephant logo appeared.
The rest is history: shortly after PHP 4 came Drupal; in 2003 we got WordPress; then in 2004 along came a student at Harvard named Mark.
Facebook and PHP
Facebook famously started as a PHP site. But when thousands of users became millions, and millions were beginning to look like billions, there were growing pains.
In particular, PHP was (and still is) a scripting language. Great for developer productivity, not so great for resource efficiency. So in 2008, Facebook began work on HipHop for PHP, a transpiler. Very simply, it parsed PHP, transpiled it to C++, then compiled the resulting C++ into x64. This was no mean feat given that PHP is weakly-typed and dynamic. But the results speak for themselves: a 50% reduction in CPU load.
I’m sure you’re imagining the horror of working as a developer at Facebook using this process. Making a change to the PHP code, running the transpiler, then compiler, drumming your fingers, running the executable and finding the problem you need to go back and fix. That’s a pretty long iteration cycle, which is why Facebook also developed HPHPi, an interpreter that does the same job as the transpiler/compiler (HPHPc), but just to be used for development. As you can imagine, keeping the two projects in sync was an almighty headache, so in 2011 they developed HHVM, the HipHop Virtual Machine.
HHVM is a PHP runtime. It uses JIT (just-in-time) compilation to provide the best of both worlds. It’s pretty cool, and you can read more in Facebook’s own blog post if you’re interested. The next big step came in 2014, with the invention of Hack, a language specifically built for HHVM. It’s both a superset and subset of PHP, adding optional type annotations and extra features such as asynchronous architecture. It also helps make HHVM’s JIT more efficient by enabling it to optimise with confidence using the specified type hints. Soon, new code at Facebook was written in Hack, with existing code being converted over time. Both Hack and HHVM are open source, and actively maintained today.
Does the fact that Facebook found PHP in its native form unusable at scale mean that it’s a badly engineered language? No, I don’t think so. I don’t believe any of the options which were around at the time had been created for the scale or specifics which Facebook required. However, that doesn’t stop people using it against PHP.
The Hate
Within the wider software community, as PHP became larger it inevitably drew fire from a growing group of cynics. Except, PHP objectively speaking gets more hate than most other languages. According to the recent 2020 Stack Overflow Developer Survey, PHP is the sixth most dreaded language. Why?
I don’t want to get into technical minutiae here, but if you do, PHP: a fractal of bad design, is the bible blog post for PHP haters. Written in 2012, some problems it mentions have since been fixed but many haven’t. (eg: why is there no native async support in 2020?)
Stack Overflow 2020 survey of most dreaded languages
I think more general problems lie in the philosophy of the language. It’s a tool for a fairly narrow domain, implemented in a complex way. In an ideal world, if an application must be complex, the complexity should be visible to the developer in user code, not the language itself. You don’t need a complex tool to create complex projects. When I say PHP is complex, I’m not saying it’s hard for beginners to use (quite the opposite in fact), I’m saying it has inconsistent naming conventions and a lot of very specific functions, both make it easy to create errors which aren’t caught until runtime. But are these simply properties of PHP’s age, to be expected? Whilst perhaps a factor, it’s certainly isn’t the reason for the hate. After all, Python was created in 1989, six years before PHP, and comes in as the 3rd most loved language in the Stack Overflow survey, as well as being one of the fastest-growing languages today.
When it comes to security, there’s some debate as to whether the above-average number of vulnerabilities on PHP sites are the fault of the language or the site developers. On the one hand, a coding language designed to appeal to a broad range of people including non-programmers, who produce sites with code hacked together from decades-old tutorials will always have issues, no matter the merit of the language itself. On the other hand, PHP has attempted to fix basic security issues in questionably convoluted ways, for example fixing SQL injection first with escape_string(), then fixing vulnerabilities with that by adding real_escape_string(), then adding addslashes(), mysql_escape_string(), pg_escape_string() and so on. Add this to its labyrinthine error/exception handling (yes, errors and exceptions are different), and it’s easy to make mistakes if you’re not well versed in the nuances of the language. The amount of sites running old, unsupported versions of PHP past their End Of Life continues to be staggeringly large, so PHP sites will continue to be low-hanging fruits for hackers for years to come.
Be this as it may, I’m not convinced that the problems the language has are as large as many would make out. Despite there being reasonable grounds for complaint about PHP, it seems to me that much of the stigma is absorbed because it’s fashionable, rather than reasoned by individuals.
The Future
This author is well aware of the irony of typing critiques of the language into a page with post.php in the address bar. But this isn’t about existing sites. I don’t think even the most ardent pitchfork mobs would suggest that we re-write all existing sites made with PHP. The question is, in June 2020, if I want to create a new website, should PHP be an option I consider?
There is no doubt that the current web development trends are setting a course for Single Page Applications – where your browser never reloads, but navigations occur from Javascript re-rendering the page using data from lightning-fast API calls (eg: browsing GitHub or Google Drive). There is an ever-growing ecosystem of Javascript libraries, frameworks, and tools for building reactive and performant applications in the browser — React and Vue being the most popular.
Ultimately, PHP is for server-side rendering. That’s fine for most sites and the best option for many. But if you’re building something new in 2020, you have to accept that this brings limitations. And whilst PHP-style server-side rendering isn’t dead (did everyone forget about SEO?), modern sites are likely to be Isomorphic, that is, able to render the same Javascript on server and client, using frameworks such as Next.js (for React) or Nuxt.js (for Vue), putting PHP out of business on the server.
But we can’t ignore the fact that PHP is evolving too. Laravel, self-publicised as “The PHP Framework for web artisans”, provides an MVC architecture for creating PHP applications safely and quickly. It’s held in high esteem by the community, and enjoys active and rapid development. Additionally, PHP 8 is coming out later this year, with a bunch of new features (many of which will look familiar from the Facebook section), such as a JIT, Union types, and improved errors.
So, happy twenty-fifth birthday PHP, you are endlessly quirky and will undoubtedly endure for many more years. You’ve empowered many people and played a key role in the rise of the web. But don’t be too upset if people are looking elsewhere for the future, it’s 2020 after all.
In June, 1995, Rasmus Lerdorf made an announcement on a Usenet group. You can still read it.
Announcing the Personal Home Page Tools (PHP Tools) version 1.0.
These tools are a set of small tight cgi binaries written in C.
Today, twenty five years on, PHP is about as ubiquitous as it could possibly have become. I’d be willing to bet that for the majority of readers of this article, their first forays into web programming involved PHP.
But no matter what rich history and wide userbase PHP holds, that’s no justification for its use in a landscape that is rapidly evolving. Whilst PHP will inevitably be around for years to come in existing applications, does it have a future in new sites?
Before we look to the future, we must first investigate how PHP has evolved in the past.
The Beginnings
Rasmus Lerdorf initially created PHP as a way to track users who visited his online CV. Once the source code had been released and the codebase had been re-written from scratch a sizeable number of times, PHP was enjoying some popularity, reportedly being installed on 1% of all domains by 1998. At this point, the language looked nothing like we know today. It was entirely written within <!-- html comments -->, with syntax noticeably different to modern versions.
Enter Zeev Suraski and Andi Gutmans, who were using PHP to try to build a business but found it lacking in features. Collaborating with Rasmus, PHP was once again re-written and released as PHP 3.0. Now we’re getting somewhere, with PHP 3 installed on an estimated 10% of domains at the time. This is also the point where the meaning of PHP changed from Personal Home Page to everyone’s favorite recursive acronym, “PHP: Hypertext Preprocessor”. This version and period is generally seen as the time in which PHP cemented its future status. Between PHP 3 and 4, phpMyAdmin was created, Zeev and Andi mashed their names together and founded the PHP services company Zend, and the venerable elephant logo appeared.
The rest is history: shortly after PHP 4 came Drupal; in 2003 we got WordPress; then in 2004 along came a student at Harvard named Mark.
Facebook and PHP
Facebook famously started as a PHP site. But when thousands of users became millions, and millions were beginning to look like billions, there were growing pains.
In particular, PHP was (and still is) a scripting language. Great for developer productivity, not so great for resource efficiency. So in 2008, Facebook began work on HipHop for PHP, a transpiler. Very simply, it parsed PHP, transpiled it to C++, then compiled the resulting C++ into x64. This was no mean feat given that PHP is weakly-typed and dynamic. But the results speak for themselves: a 50% reduction in CPU load.
I’m sure you’re imagining the horror of working as a developer at Facebook using this process. Making a change to the PHP code, running the transpiler, then compiler, drumming your fingers, running the executable and finding the problem you need to go back and fix. That’s a pretty long iteration cycle, which is why Facebook also developed HPHPi, an interpreter that does the same job as the transpiler/compiler (HPHPc), but just to be used for development. As you can imagine, keeping the two projects in sync was an almighty headache, so in 2011 they developed HHVM, the HipHop Virtual Machine.
HHVM is a PHP runtime. It uses JIT (just-in-time) compilation to provide the best of both worlds. It’s pretty cool, and you can read more in Facebook’s own blog post if you’re interested. The next big step came in 2014, with the invention of Hack, a language specifically built for HHVM. It’s both a superset and subset of PHP, adding optional type annotations and extra features such as asynchronous architecture. It also helps make HHVM’s JIT more efficient by enabling it to optimise with confidence using the specified type hints. Soon, new code at Facebook was written in Hack, with existing code being converted over time. Both Hack and HHVM are open source, and actively maintained today.
Does the fact that Facebook found PHP in its native form unusable at scale mean that it’s a badly engineered language? No, I don’t think so. I don’t believe any of the options which were around at the time had been created for the scale or specifics which Facebook required. However, that doesn’t stop people using it against PHP.
The Hate
Within the wider software community, as PHP became larger it inevitably drew fire from a growing group of cynics. Except, PHP objectively speaking gets more hate than most other languages. According to the recent 2020 Stack Overflow Developer Survey, PHP is the sixth most dreaded language. Why?
I don’t want to get into technical minutiae here, but if you do, PHP: a fractal of bad design, is the bible blog post for PHP haters. Written in 2012, some problems it mentions have since been fixed but many haven’t. (eg: why is there no native async support in 2020?)
Stack Overflow 2020 survey of most dreaded languages
I think more general problems lie in the philosophy of the language. It’s a tool for a fairly narrow domain, implemented in a complex way. In an ideal world, if an application must be complex, the complexity should be visible to the developer in user code, not the language itself. You don’t need a complex tool to create complex projects. When I say PHP is complex, I’m not saying it’s hard for beginners to use (quite the opposite in fact), I’m saying it has inconsistent naming conventions and a lot of very specific functions, both make it easy to create errors which aren’t caught until runtime. But are these simply properties of PHP’s age, to be expected? Whilst perhaps a factor, it’s certainly isn’t the reason for the hate. After all, Python was created in 1989, six years before PHP, and comes in as the 3rd most loved language in the Stack Overflow survey, as well as being one of the fastest-growing languages today.
When it comes to security, there’s some debate as to whether the above-average number of vulnerabilities on PHP sites are the fault of the language or the site developers. On the one hand, a coding language designed to appeal to a broad range of people including non-programmers, who produce sites with code hacked together from decades-old tutorials will always have issues, no matter the merit of the language itself. On the other hand, PHP has attempted to fix basic security issues in questionably convoluted ways, for example fixing SQL injection first with escape_string(), then fixing vulnerabilities with that by adding real_escape_string(), then adding addslashes(), mysql_escape_string(), pg_escape_string() and so on. Add this to its labyrinthine error/exception handling (yes, errors and exceptions are different), and it’s easy to make mistakes if you’re not well versed in the nuances of the language. The amount of sites running old, unsupported versions of PHP past their End Of Life continues to be staggeringly large, so PHP sites will continue to be low-hanging fruits for hackers for years to come.
Be this as it may, I’m not convinced that the problems the language has are as large as many would make out. Despite there being reasonable grounds for complaint about PHP, it seems to me that much of the stigma is absorbed because it’s fashionable, rather than reasoned by individuals.
The Future
This author is well aware of the irony of typing critiques of the language into a page with post.php in the address bar. But this isn’t about existing sites. I don’t think even the most ardent pitchfork mobs would suggest that we re-write all existing sites made with PHP. The question is, in June 2020, if I want to create a new website, should PHP be an option I consider?
There is no doubt that the current web development trends are setting a course for Single Page Applications – where your browser never reloads, but navigations occur from Javascript re-rendering the page using data from lightning-fast API calls (eg: browsing GitHub or Google Drive). There is an ever-growing ecosystem of Javascript libraries, frameworks, and tools for building reactive and performant applications in the browser — React and Vue being the most popular.
Ultimately, PHP is for server-side rendering. That’s fine for most sites and the best option for many. But if you’re building something new in 2020, you have to accept that this brings limitations. And whilst PHP-style server-side rendering isn’t dead (did everyone forget about SEO?), modern sites are likely to be Isomorphic, that is, able to render the same Javascript on server and client, using frameworks such as Next.js (for React) or Nuxt.js (for Vue), putting PHP out of business on the server.
But we can’t ignore the fact that PHP is evolving too. Laravel, self-publicised as “The PHP Framework for web artisans”, provides an MVC architecture for creating PHP applications safely and quickly. It’s held in high esteem by the community, and enjoys active and rapid development. Additionally, PHP 8 is coming out later this year, with a bunch of new features (many of which will look familiar from the Facebook section), such as a JIT, Union types, and improved errors.
So, happy twenty-fifth birthday PHP, you are endlessly quirky and will undoubtedly endure for many more years. You’ve empowered many people and played a key role in the rise of the web. But don’t be too upset if people are looking elsewhere for the future, it’s 2020 after all.
In June, 1995, Rasmus Lerdorf made an announcement on a Usenet group. You can still read it.
Announcing the Personal Home Page Tools (PHP Tools) version 1.0.
These tools are a set of small tight cgi binaries written in C.
Today, twenty five years on, PHP is about as ubiquitous as it could possibly have become. I’d be willing to bet that for the majority of readers of this article, their first forays into web programming involved PHP.
But no matter what rich history and wide userbase PHP holds, that’s no justification for its use in a landscape that is rapidly evolving. Whilst PHP will inevitably be around for years to come in existing applications, does it have a future in new sites?
Before we look to the future, we must first investigate how PHP has evolved in the past.
The Beginnings
Rasmus Lerdorf initially created PHP as a way to track users who visited his online CV. Once the source code had been released and the codebase had been re-written from scratch a sizeable number of times, PHP was enjoying some popularity, reportedly being installed on 1% of all domains by 1998. At this point, the language looked nothing like we know today. It was entirely written within <!-- html comments -->, with syntax noticeably different to modern versions.
Enter Zeev Suraski and Andi Gutmans, who were using PHP to try to build a business but found it lacking in features. Collaborating with Rasmus, PHP was once again re-written and released as PHP 3.0. Now we’re getting somewhere, with PHP 3 installed on an estimated 10% of domains at the time. This is also the point where the meaning of PHP changed from Personal Home Page to everyone’s favorite recursive acronym, “PHP: Hypertext Preprocessor”. This version and period is generally seen as the time in which PHP cemented its future status. Between PHP 3 and 4, phpMyAdmin was created, Zeev and Andi mashed their names together and founded the PHP services company Zend, and the venerable elephant logo appeared.
The rest is history: shortly after PHP 4 came Drupal; in 2003 we got WordPress; then in 2004 along came a student at Harvard named Mark.
Facebook and PHP
Facebook famously started as a PHP site. But when thousands of users became millions, and millions were beginning to look like billions, there were growing pains.
In particular, PHP was (and still is) a scripting language. Great for developer productivity, not so great for resource efficiency. So in 2008, Facebook began work on HipHop for PHP, a transpiler. Very simply, it parsed PHP, transpiled it to C++, then compiled the resulting C++ into x64. This was no mean feat given that PHP is weakly-typed and dynamic. But the results speak for themselves: a 50% reduction in CPU load.
I’m sure you’re imagining the horror of working as a developer at Facebook using this process. Making a change to the PHP code, running the transpiler, then compiler, drumming your fingers, running the executable and finding the problem you need to go back and fix. That’s a pretty long iteration cycle, which is why Facebook also developed HPHPi, an interpreter that does the same job as the transpiler/compiler (HPHPc), but just to be used for development. As you can imagine, keeping the two projects in sync was an almighty headache, so in 2011 they developed HHVM, the HipHop Virtual Machine.
HHVM is a PHP runtime. It uses JIT (just-in-time) compilation to provide the best of both worlds. It’s pretty cool, and you can read more in Facebook’s own blog post if you’re interested. The next big step came in 2014, with the invention of Hack, a language specifically built for HHVM. It’s both a superset and subset of PHP, adding optional type annotations and extra features such as asynchronous architecture. It also helps make HHVM’s JIT more efficient by enabling it to optimise with confidence using the specified type hints. Soon, new code at Facebook was written in Hack, with existing code being converted over time. Both Hack and HHVM are open source, and actively maintained today.
Does the fact that Facebook found PHP in its native form unusable at scale mean that it’s a badly engineered language? No, I don’t think so. I don’t believe any of the options which were around at the time had been created for the scale or specifics which Facebook required. However, that doesn’t stop people using it against PHP.
The Hate
Within the wider software community, as PHP became larger it inevitably drew fire from a growing group of cynics. Except, PHP objectively speaking gets more hate than most other languages. According to the recent 2020 Stack Overflow Developer Survey, PHP is the sixth most dreaded language. Why?
I don’t want to get into technical minutiae here, but if you do, PHP: a fractal of bad design, is the bible blog post for PHP haters. Written in 2012, some problems it mentions have since been fixed but many haven’t. (eg: why is there no native async support in 2020?)
Stack Overflow 2020 survey of most dreaded languages
I think more general problems lie in the philosophy of the language. It’s a tool for a fairly narrow domain, implemented in a complex way. In an ideal world, if an application must be complex, the complexity should be visible to the developer in user code, not the language itself. You don’t need a complex tool to create complex projects. When I say PHP is complex, I’m not saying it’s hard for beginners to use (quite the opposite in fact), I’m saying it has inconsistent naming conventions and a lot of very specific functions, both make it easy to create errors which aren’t caught until runtime. But are these simply properties of PHP’s age, to be expected? Whilst perhaps a factor, it’s certainly isn’t the reason for the hate. After all, Python was created in 1989, six years before PHP, and comes in as the 3rd most loved language in the Stack Overflow survey, as well as being one of the fastest-growing languages today.
When it comes to security, there’s some debate as to whether the above-average number of vulnerabilities on PHP sites are the fault of the language or the site developers. On the one hand, a coding language designed to appeal to a broad range of people including non-programmers, who produce sites with code hacked together from decades-old tutorials will always have issues, no matter the merit of the language itself. On the other hand, PHP has attempted to fix basic security issues in questionably convoluted ways, for example fixing SQL injection first with escape_string(), then fixing vulnerabilities with that by adding real_escape_string(), then adding addslashes(), mysql_escape_string(), pg_escape_string() and so on. Add this to its labyrinthine error/exception handling (yes, errors and exceptions are different), and it’s easy to make mistakes if you’re not well versed in the nuances of the language. The amount of sites running old, unsupported versions of PHP past their End Of Life continues to be staggeringly large, so PHP sites will continue to be low-hanging fruits for hackers for years to come.
Be this as it may, I’m not convinced that the problems the language has are as large as many would make out. Despite there being reasonable grounds for complaint about PHP, it seems to me that much of the stigma is absorbed because it’s fashionable, rather than reasoned by individuals.
The Future
This author is well aware of the irony of typing critiques of the language into a page with post.php in the address bar. But this isn’t about existing sites. I don’t think even the most ardent pitchfork mobs would suggest that we re-write all existing sites made with PHP. The question is, in June 2020, if I want to create a new website, should PHP be an option I consider?
There is no doubt that the current web development trends are setting a course for Single Page Applications – where your browser never reloads, but navigations occur from Javascript re-rendering the page using data from lightning-fast API calls (eg: browsing GitHub or Google Drive). There is an ever-growing ecosystem of Javascript libraries, frameworks, and tools for building reactive and performant applications in the browser — React and Vue being the most popular.
Ultimately, PHP is for server-side rendering. That’s fine for most sites and the best option for many. But if you’re building something new in 2020, you have to accept that this brings limitations. And whilst PHP-style server-side rendering isn’t dead (did everyone forget about SEO?), modern sites are likely to be Isomorphic, that is, able to render the same Javascript on server and client, using frameworks such as Next.js (for React) or Nuxt.js (for Vue), putting PHP out of business on the server.
But we can’t ignore the fact that PHP is evolving too. Laravel, self-publicised as “The PHP Framework for web artisans”, provides an MVC architecture for creating PHP applications safely and quickly. It’s held in high esteem by the community, and enjoys active and rapid development. Additionally, PHP 8 is coming out later this year, with a bunch of new features (many of which will look familiar from the Facebook section), such as a JIT, Union types, and improved errors.
So, happy twenty-fifth birthday PHP, you are endlessly quirky and will undoubtedly endure for many more years. You’ve empowered many people and played a key role in the rise of the web. But don’t be too upset if people are looking elsewhere for the future, it’s 2020 after all.
When [Neutrino-1] saw DFRobot’s DFPlayer module, he decided he wanted to make his own retro MP3 player. This tiny module comes packed with a ton of interesting capabilities such as EQ adjustment, volume control, and a 3 watt amplifier amongst other things. It can even play ads in between songs, should you want such a thing.
Controlling the DFPlayer module is easy using serial commands from a microcontroller, making it a convenient subsystem in bigger projects, and a potential alternative to the popular VLSI chips or the hard to come by WT2003S IC. [Neutrino-1] does a good job walking readers through the build making it fairly easy to remix, reuse, and reshare.
With the hardware sorted, all you’ve got to do is flash the firmware and load up an SD card with some MP3s. There’s even a small Python GUI to help you get your new player up and running. [Neutrino-1] also introduces users to the U8g2 display library which he says is a bit more feature-rich than the common Adafruit SSD1306 library. Great job [Neutrino-1]!
The term “vacuum” means many different things depending whether you are working on space equipment, scientific instruments, or even internal combustion engines. In our sphere it is so often used as a means to draw bubbles out of resin castings, for which it is a relatively easily achievable partial vacuum. It’s something [Fab] is using, in a vacuum chamber made from Plexiglass.
A simple Plexiglass box would collapse under the air pressure on its own, so to mitigate that it’s made from a piece of tube, and with an internal frame of aluminium extrusion with 3D printed joints to strengthen it from the inside. A pressure sensor allows regulation of the pump that drives the vacuum, and connections are made to the chamber using pneumatic hose connectors. It’s not immediately clear how it is sealed, whether there are nay gaskets or other sealant, or whether air pressure pushing the parts together provides enough of a seal.
We’ve featured a lot of vacuum chambers made for this purpose over the years, and we’d be interested to know what vacuum pump is being used here. If you’re curious too and want to build your own, perhaps you could try a fridge compressor.
So that’s the easy part. But how do you spin it? The operator uses a foot pedal attached to a piece of rope that’s been wound around the log and attached to a slender pole cantilevered out over the lathe. By adjusting the length and angle of this pole, the user can set the amount of force it takes to depress the pedal. When the pedal is pushed down the log will spin one way, and when the pole pulls the pedal back up, it will spin the other.
I’m sure you’re imagining the horror of working as a developer at Facebook using this process. Making a change to the PHP code, running the transpiler, then compiler, drumming your fingers, running the executable and finding the problem you need to go back and fix. That’s a pretty long iteration cycle, which is why Facebook also developed HPHPi, an interpreter that does the same job as the transpiler/compiler (HPHPc), but just to be used for development. As you can imagine, keeping the two projects in sync was an almighty headache, so in 2011 they developed HHVM, the HipHop Virtual Machine.
There is no doubt that the current web development trends are setting a course for Single Page Applications – where your browser never reloads, but navigations occur from Javascript re-rendering the page using data from lightning-fast API calls (eg: browsing GitHub or Google Drive). There is an ever-growing ecosystem of Javascript libraries, frameworks, and tools for building reactive and performant applications in the browser — React and Vue being the most popular.