Tech

With Sinatra, I was using DataMapper as ORM (Object Relational Mapper) for Postgres, and I got a bit spoiled, because it makes things really easy. You first have to define your data mapping:

class Post
  include DataMapper::Resource
  # Set the number of characters for these types of fields, if the DB supports it
  DataMapper::Property::String.length(255)
  DataMapper::Property::Text.length(999999)
  property :id, Serial
  property :title, Text
  property :body, Text
  property :datetime, String
  property :modified, String
  property :link, String
end

And using it is really straightforward:

In the previous posts I mentioned file locations, but I haven't been explicit on what my structure is, so let's go through it:

Express 2.0 apparently had layouts and partials included, but they were removed in 3.0. Luckily, ejs-mate has us covered.

Let's quickly cover partials, because it feels a bit easier. First, the partial, inside an example.ejs file, located in the same views folder where all your views are kept (preferably inside a nested partials folder):

<p>I am a partial</p>
And I will be included too

Then, when we want this bit of code in another file, we can just include it where it's needed:

<h1>About me</h1>
<% include ./partials/example >
More stuff here

This will be rendered as:

Express offers a really easy routing system, which is the main selling point:

var app = require('express')()
app.use('/', require('./routes/routes'))

This will delegate all routing to the routes.js file, inside the routes folder, at the root level. Here, we delegate individual routes to their specific files, but declaring routes will be just as easy:

var router = require('express').Router()
 
router.use('/privacy-policy', require('./privacy-policy'))
router.use('*', function(req, res) { // req stands for request, res for response
  res.render('not-found') // This is the 404 page, and should be the last route
})
 
module.exports = router

As I said in my previous post, I will do a suite of posts regarding the migration of my website from ruby to Node.js, and to make them easier to spot, I will prefix them with [NJS]. Small warning: I'm not a semicolon user. I've read quite a bit about it, and I made my choice knowingly.

So, the first thing I picked was Express, a really nice web application framework. All it takes to have it running is:

var app = require('express')()
 
app.get('/', function(req, res) {
  res.render('index', { name: 'Roland' })
})
app.listen(process.env.PORT || 3000)
app.set('view engine', 'ejs')

Recently I started working on a Node.js project, but since I barely wrote like 50 lines of JS code, ever, I decided to migrate my current ruby based website to a Node.js one, to familiarize with it a bit. In my upcoming posts I will write about how everything goes.

I'm pretty pro null and type safety, so the main thing I'm wondering right now is how I'll feel after writing JS for a while, since it's at the other end of the spectrum compared to Swift: none vs 100% strictness.

Having to create the same set of buttons over and over can become cumbersome. We'll try to make use of protocols and implement some default ones. Let's start with that:

We all hate explicitly typed strings, especially for creating UIImages, but we can surely improve on that. Let's start with an enum, that has a var, to transform its raw value into an UIImage:

enum Asset: String {
  case back = "leftArrow"
  case logo
  case email
  case briefcase
	
  // Theoretically, a bang wouldn't be that bad here, 
  // as we should be 100% sure of what goes in this enum
  var image: UIImage? {
    return UIImage(named: rawValue)
  }
}

And why not improve UIImageView too, while we're at it?

extension UIImageView {
  convenience init(asset: Asset) {
    self.init(image: asset.image)
  }
}

I was reading Shannon's post about shape layers, and one of the resources he links to is this page about fill rules. It was interesting to see the inner workings of them. Go and bookmark calayer.com, as well!

The following snapping logic is for a collection with cells of the same size and one section, but the logic for more sections shouldn't be much different, or much more complex.

scrollViewWillEndDragging has an inout targetContentOffset parameter, meaning we can read and modify the end position of the scroll. Luckily, we don't need to take into consideration insets, line or item spacing (I've lost a lot of time by including them, then not being able to understand why the correct math produces wrong results):