Real Favicon Generator is a handy tool for setting up your website’s favicon properly. It takes care of both the images (formats, resolutions, etc) and the HTML that you’ll need to include. With just a few clicks your website will work properly with browsers, operating systems, and mobile applications.
With so many platforms and icons, it’s hard to know exactly what you should do. What are the dimensions of favicon.ico? How many Touch icons do I need? RealFaviconGenerator did the reseach and testing for you.
If you still prefer to do it yourself and know all there is to generating proper favicon images and markup, have a look at this resource for everything there is to it and more.
CSV, or comma-separated values, is a very common format for managing all kinds of configurations, as well data manipulation. As the linked Wikipedia page mentions, there are a few RFCs that try to standardize the format. However, I thought, there is still a lack of schema-type standard that would allow one to define a format for particular file.
Today I came across an effort that attempts to do just that – CSV Schema Language v1.1 – an unofficial draft of the language for defining and validating CSV data. This is work in progress by the Digital Preservation team at The National Archives.
Apart from the unofficial draft of the language, there is also an Open Source CSV Validator v1.1 application, written in Scala.
PHP Package Development Standard, aka pds/skeleton, is now stable. I’ve linked to it before and I think it’s a great idea and I’m glad I’m not alone:
Roughly 78,000 packages already comply with the
pds/skeleton standard, although they may not know it. To formally show that your package has adopted the standard, “require-dev” it via Composer, or display a badge on your README.
I’d gladly follow this standard for my own work too, except that I mostly work with WordPress and CakePHP these days, both of which do things differently from the standard and from each other.
WordPress kind of assumes that the whole project is public, so you don’t really get public/ folder. It also organizes the code into wp-includes/, wp-admin/ and wp-content/ folders, instead of the src/ suggested by PDS. And, in terms of configuration, everything goes into wp-config.php file instead of something in the config/ folder.
CakePHP is much closer to PDS in terms of organization of files. The only difference that I can spot is the use of webroot/ folder instead of the suggested public/.
I’d really love to see larger libraries and frameworks adhere to the PDS, but until that happens, I’ll keep an eye on things.
P.S.: The standards comic strip is of course from xkcd.
Wait, what? That’s exactly what I said when I read this blog post. I am still making my way through the JSON API specification. And now it seems I might be wasting my time, as I should be learning HAL.
Whereas JSON API is almost like an “ORM over HTTP”, HAL does a lot less for you though, so it’s not really an apples-to-apples type of comparison.
HAL really is just a document format for a hypermedia API, like HTML is for hypertext. It doesn’t tell you how to express your domain model, and doesn’t really tell you how to use HAL to submit changes.
Sometime I think that I should just stop learning. What’s the point? By the time you learn a thing or two, it’s already obsolete and somebody somewhere has created something better, or wiser, or cheaper.
Paul M. Jones announces the availability of PHP Package Development Standards for review:
This initiative researches the PHP package ecosystem to recognize commonly adopted development practices. It rationalizes and refines those practices, then publishes them as PDS packages for reference by PHP package authors.
PDS publications are derived from and supported by common practices existing in real packages, as adopted by existing authors who have a continuing interest in the quality and consistency of their own work.
Have a look at php-pds/skeleton GitHub repository.
Personally, I welcome this initiative. PHP ecosystem exploded in the recent years with the help of composer and Packagist.org. There are over 120,000 packages just on the Packagist.org. I think, it’s good to have some standards and best practices. The PHP Framework Interop Group (PHP-FIG) is doing its best with the PHP Standards Recommendations (PSRs). But we could have some more guidelines in order to have some consistency.
PHP Package Development Standards takes, in my opinion, the right way of looking at what’s out there, what works and what doesn’t, and than setting the guidelines based on the real world practices. They cover things like file and directory naming conventions, versioning, changelog and licensing – which are common issues for pretty much every package.
Looking at the packages that I am involved with, only a few minor changes are necessary to comply. Mostly, the “config” folder instead of the Unix-style “etc“, CONTRIBUTING file, and a CHANGELOG file, which I’m still to find a good way to semi-automate.
I thought I did. Especially after all the hours spent with Ansible. Turns out I don’t. I have a very limited understanding of the YAML format. How do I know that, you ask? Well, that’s because I am reading the YAML specification now.
Holy Molly that’s an interesting format! Much recommended weekend reading.
The History of the URL is a brilliant compilation of ideas and resources, explaining how we got to the URLs we use and love (or hate) today. In fact, the article comes in two parts:
- Domain, protocol, and port
- Path, fragment, query, and auth
Read them in whatever order you prefer. But I guarantee that you’ll have a number of different responses through out, from “Wow! I never knew that” and “I would have never thought of that!” to “No way! I don’t believe it“.
And here is one of the bits that made me smile:
In 1996 Keith Shafer, and several others proposed a solution to the problem of broken URLs. The link to this solution is now broken. Roy Fielding posted an implementation suggestion in July of 1995. The link is now broken.
OpenAPI Specification v2.0 – formerly known as Swagger RESTful API Documentation Specification.
Swagger™ is a project used to describe and document RESTful APIs.
The Swagger specification defines a set of files required to describe such an API. These files can then be used by the Swagger-UI project to display the API and Swagger-Codegen to generate clients in various languages. Additional utilities can also take advantage of the resulting files, such as testing tools.
Read “Color Profiles & Printing – Explained“. The infographic is much handy too.
International Electrotechnical Commission has a very handy (especially before travelling to a foreign country) list of different plugs (a total of 14 at the time of this writing), mapped to countries of the world. So if you don’t have one of these:
make sure you check the list before you fly out. And while on the topic of this great variety, IEC also explains why there are so many and if this annoyance will ever be sold:
The IEC issued its International Standard for a universal plug in the 1970s; so far it has been adopted by Brazil and South Africa. It is unlikely that there will be a run on the standard in the near future. Literally hundreds of millions of plugs and sockets have been installed and who would convince a country to invest now in changing its whole infrastructure?
Most likely the future will lie with solutions such as the USB plug or possibly a multi-plug that can accommodate many different plugs, or even new technologies such as LVDC (low voltage direct current) or wireless charging mechanisms.