One important thing for a good user experience is a fast website. Google offers the free tool Page Speed Insights. Running it initially on my website I already have a score of 99, which is pretty good. In the past I already spent a fair amount of time optimizing the bigger problems.
Rails provides a great way to check for nil
and empty variables in the same call: blank?
. This is especially helpful in ERB templates where a variable can be either nil or empty, depending on the object. Without it, the check would look similar to this:
<% unless obj.nil? and obj != "" %>
<%= obj %>
<% end %>
blank?
, this can be simplified to:
<% unless obj.blank? %>
<%= obj %>
<% end %>
blank?
returns true
and false
respectively:
"".blank?
=> true
nil.blank?
=> true
"hello".blank?
=> false
5.blank?
=> false
AnyClass.blank?
=> false
I finally followed through with my plan from 2017 to install JSONFeed for this blog.
jsonify
from the liquid template language. Overall, it was easier to get an XML feed to work as JSON is very picky about escaping of double quotes and other special HTML characters. My template for Jekyll is saved as feed.json
and looks as follows:
---
layout: null
---
{
"version": "https://jsonfeed.org/version/1.1",
"title": {{ site.title | jsonify }},
"description": {{ site.description | strip_newlines | jsonify }},
"language": "{{ site.language }}",
"home_page_url": "{{ site.url }}{{ site.baseurl }}",
"feed_url": "{{ site.url }}{{ site.baseurl }}/feed.json",
"items": [
{% for post in site.posts limit:100 %}
{
"id": "{{ post.url | prepend: site.baseurl | prepend: site.url }}",
"url": "{{ post.url | prepend: site.baseurl | prepend: site.url }}",
"title": {{ post.title | jsonify }},
"content_html": {{ post.content | strip_newlines | jsonify }},
"date_published": "{{ post.date | date_to_xmlschema }}"
}{% unless forloop.last %},{% endunless %}
{% endfor %}
]
}
Buy the nicest screwdrivers you can afford.Source
Probably not so much, or at least less than you might think.
We often need to store dates and times in a database and retrieve them later. I have seen people choosing to store those in the highest precision available. For example, in Python the precision for a datetime
object is microseconds. That is one millionth of a second!
For a lot of use cases, this kind of precision is not needed. For many
cases, second precision is enough. Examples for use-cases that probably don’t need the highest precision are:
DATETIME(3)
type where the number denotes the sub-second precision. Defining the precision explicitly makes it not only more predictable in your code, it also avoid wasting space.
As usual, it depends on the use case. It does make sense to think a little bit about the precision to avoid problems later in the development process.