Making it to Github, eventually

After only 4 years and a half since the last post, I have quite some big news: I finally created my first project on Github.

I'm not really sure it's production-ready, but it technically works and it has a minimum of documentation, so I thought I'd publish it.

It's an algorithm to anonymize hierarchically-structured data, using a multi-level approach, hence a "multi-level anonymizer".

It lives here:
https://github.com/xfranky/ml-anonymizer

I'm still trying to better document the internal working of the classes, and eventually there might be a big rewrite to make it usable for more generic problems rather than the very specific use case it was created for, which is anonymizing transfer speed of connections by provenience.

More to follow, hopefully...

Devise: redirect to specific pages after sign in using different models

As you should know, Devise can be applied in the same project to different models, but I couldn't find a simple way to redirect users after signing in, based on the kind of resource they were representing (e.g. let's say users and vendors).

After searching for long how to solve this issue and finding long and winding solutions, I found a way to solve it myself in a very simple way; as it is here it's really bare bones and possibly prone to bugs, but it does exactly what I wanted, so I thought other people might find it interesting.

So, let's say we are using Devise on the user and vendor models, and we generated our custom session controllers in user/sessions_controller.rb and vendor/sessions_controller.rb. The first thing that came to my mind was to find a way to customize the redirection from the controllers by overwriting some of the functions, but it turned out to be complicated and not working as expected.

As such I came out with a much simpler even though less elegant solution; that is overwriting the default function after_sign_in_path_for(resource) in the application controller, checking whether in my session I have an instance of one kind of resource or the other.

Here is the relevant code:

class ApplicationController < ActionController::Base
  
  [...]

  def after_sign_in_path_for(resource)
    if current_user
      "your_user_url"
    elsif current_vendor
      "your_vendor_url"
    end
  end
end

I hope this will help you as much as it helped me.

The old website challenge - 04 - Setting the viewport

It's renown that Google penalizes in its ranking the websites which are not mobile-friendly. As such, one of the priorities with modernizing my old website is to make it mobile friendly. The first step to do this is to implement the viewport property in the HTML code of the pages.

What's the viewport?

I'm not going to invent anything and I rely on W3schools' definition saying that

The viewport is the user's visible area of a web page.

Thus configuring the viewport means being in control of how our website adapts to the screen of any device instead of letting the user's device deciding how to adapt the website to the screen.

The default behavior of most mobile devices, without a properly configured viewport, is to set an arbitrary width (the most common is 980px), render the website as it would appear on a screen of that width, and zoom out until the view matches the device's screen width. Clever, but the results are not always predictable, and especially often not easy to navigate through.

As our objective is to have a responsive website, we want our viewport to always match the device width with no zooming in or out involved. The code to use in order to do that, adding it to the head section of the html document, is the following:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

By doing so we are telling the browser to always size the content of the website to the width of the screen. One downside of this technique is that we need to be very careful when using fixed-size elements, as they might not fit the viewport.

The first way to try to obviate this issue is to use for potentially wide elements (e.g. pictures) the attribute max-width instead of width; this tells the browser to use the given width only when the item fits the containing block; if not, the item will be proportionally scaled until it fits.

They say that With great power come great responsibilities... well, sure, now you are in control of how the website shows and it means that you need to be the one to adapt it to the different devices! As we will see in a next post, a very convenient way to do so is by using the CSS media queries.

The Old Website Challenge - 03 - SEO and old static files

As I previously wrote, the old website I'm modernizing was rewritten in php back in 2003; yet, the old html static pages were never removed from their original folder, and are still appearing in search engines and being indexed. With some cleverness we can take that into advantage for faster indexing of the new URLs we set up in the previous post.

Going more into details, the old pages are stored in a directory named xhtml/ and their names mostly reflect the names given the files which serve the content for the php version of the website. Knowing this, we can setup a rewrite rule that can redirect the traffic directed to those old files to the new correspondent php pages.

There is one catch, though: not all old pages have the file name equal to the new one. We have two ways to solve this:

1. Change the name of the old files which do not correspond to the new ones
2. Implement a check in the rewrite configuration so that we only redirect pages with names that match the new ones

The first solution goes against the very principle of what we are doing (which is keeping the old pages in the search engines' indexes), since it will practically make the old pages with non-matching names disappear from search engines. Thus we go with the second option (which means also more fun!).

To implement the second solution, we move the old files to a new directory, which we call xhtml_old/, and then we need two rewriting rules. 

First we need a rule to redirect the old pages to the new ones:

RewriteRule ^xhtml/([a-z0-9]+).html$ p/$1 [L]

Then we need a different rule to redirect the requests for the old pages to the correspondent files in the new location:

RewriteRule ^xhtml/([a-z0-9_]+).html$ xhtml_old/$1.html [L]

...and now comes the most interesting part of today, that is deciding when one rule applies and when the other does. We can do this using the RewriteCond constructs before each of the two rules.

For the first rule, we want it to be executed when we have a content page for the CMS existing (-F option) with the same name of the old file (the $1 parameter coming from the rule):

RewriteCond include/$1.html -F

For the second rule, we want it to be executed after the first one, and in case we have the old file in the new location:

RewriteCond xhtml_old/$1.html -F

Now we can put all the pieces together in our .htaccess file, adding these lines before the rule defined in the previous post:

RewriteCond include/$1.html -F
RewriteRule ^xhtml/([a-z0-9]+).html$ p/$1 [L]
RewriteCond xhtml_old/$1.html -F
RewriteRule ^xhtml/([a-z0-9_]+).html$ xhtml_old/$1.html [L]

...and now let the crawlers re-index the old pages!

The Website Challenge - 02 - Hiding variables from the URL

The custom cms of the website uses a GET variable named pag to go into a specific folder and look for a <pagname>.html file with the page content to be loaded for each page. The result is a url which looks like this:

http://<domain.tld>/pagina.php?pag=pagname

This kind of URL is not very SEO-friendly, so I decided to use the mod_rewrite module, which is pretty much the standard on Apache installations, to turn them into something more human- and search-engine-readable.
New URLs would be in the form of

http://<domain.tld>/p/pagname

In order to do this I played around with the .htaccess file in the main directory and added the following lines:

RewriteEngine on
RewriteBase /
RewriteRule ^p/([a-z0-9]+)$ pagina.php?pag=$1 [NC,L]

The first two lines simply initialize the mod_rewrite extension since it was not previously used and tell it to calculate the addresses relative to the web root folder. The third line is the real rewriting rule, which tells to internally translate any url in the new form into the one using the GET variable; this will happen transparently, without the real address being shown to the users browsing.

To be noted is the fact that there is a debate online about whether is better to terminate URLs with a slash or not, with no clear winner. The most used strategy on CMSs is to add .html to those addresses, making dynamic pages actually look like they were static files. I might do some A/B testing in the future, but SEO is no exact science, so don't expect clear results.

The old website challenge (01)

One of the reasons that pushed me to go back updating this blog is a personal challenge I'm taking, which is modernizing an old website of mine, dating back to year 2001! The last big update to the website, namely its port to php from static html, dates back to exactly twelve years ago (December 15th, 2003); I made some other small updates later, up until September 2004.

Later my attention moved to my personal website (www.xfnet.it), leaving the other one untouched until a few weeks ago, when, for several reasons, I got interested again in WebDev, SEO, and the online development world in general.

I will document in this blog the steps I'm taking in order to take the old website into the current times. To be fair, I already took several actions, so the first few posts will be retroactive, but I believe posting every step of the process will help me get a better idea about where I'm going and about the road that I'm taking.

I know, I didn't say which website we are talking about, yet, but let's give it time :)

A new direction

Since I last updated this blog, my professional life went into a different direction; as such it's time to update the direction this blog is going to.

To begin with, it will be more focused on WebDev and online technologies.
Second ...you guessed it... I will be writing in English, as nowadays this is the language I'm expressing myself into most of the time.

As always, I cannot promise I will keep updating the blog, but I'll make another effort.

See you soon :)