https://fonts.googleapis.com/css?family=Roboto:400%2C400i%2C700%2C700i|Material+Icons,//www.planetminecraft.com/css/images.css?v=kvY01YpdGeO6piUUELHBCjnb2OQ3mBpD5hILR_LRS6XQGPFe,//www.planetminecraft.com/css/style.css?v=S-qetW-O2zMagb8ylCQvGYBbl3Q6k2KuHU7gbh1Rh5TfE_Ze,//www.planetminecraft.com/css/editor.css?v=fFZ4oryUz7URAGxJmJ0n_8XnIyREEV45rYJUNzmny3ts9vVe
GRID
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.
Meanwhile, this certainly isn’t the first PCB CAD fail we’ve brought you.
source https://hackaday.com/2020/06/29/fail-of-the-week-this-sd-card-wont-slot/
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.
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.
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.
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 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.
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?)
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.
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.
source https://hackaday.com/2020/06/29/does-php-have-a-future-or-are-twenty-five-years-enough/
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.
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 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.
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?)
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.
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.
source https://hackaday.com/2020/06/29/does-php-have-a-future-or-are-twenty-five-years-enough/
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.
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 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.
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?)
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.
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.
source https://hackaday.com/2020/06/29/does-php-have-a-future-or-are-twenty-five-years-enough/
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]!
While you’re here, take a look at some of our other MP3 projects.
source https://hackaday.com/2020/06/29/diy-pocket-mp3-player/
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.
source https://hackaday.com/2020/06/29/an-affordable-home-made-vacuum-chamber/