Playing with crystal

Last week I went to a remote meetup of Paris.rb (fr). Well, it was at 1am in my timezone, but I wanted to check how remote meetups can go and there was some presentation about crystal and about kemal. It was a great moment (video is online if you can understand french), and gave me the push to give crystal a try. It was low on my todo list but it was there, waiting for the proper conditions.

That’s pretty much the main thing that I got out of it. Attending to social activities is providing once again a great push to move forward. It’s not about what you learn (which still can be valuable), it’s not about networking with people (even if it can be priceless), it’s all about the personal alchemy that brings you on your edge and keeps you hungry for more. Well, that’s how it works for me, at least.

So I had a look at Crystal, and played a bit with Kemal, and I’m very happy with the result. I had some attempt to check Elixir too but crystal felt really much closer to ruby. The main difference being the variable typing, the stdlib that includes some modern stuff like websockets or oauth2, and the compile step (which in some case can be a bit taxing). But the speed gain is phenomenal. I suspect it would make some sense, in a scalability strategy, to think about porting ruby code to crystal when perfs become an issue (not sure how it would apply to complex rails app though).

Okay yeah Crystal is still very young. But it’s getting traction, I bet it has a bright future ahead.


Here is 2016

Well in this last week of 2015, the have not been that much publication and the list of links is shorter than usual. Everybody is probably just having a life for a change, which is a good things :)

There is a lot of promising trends that may unleash in the coming year. I hope to see what ruby 3 will bring. Rails 5 is already almost out there too. But there is some interesting move on the side of Elixir as well, even if it’s still very young and hacky in my opinion.

On the frontend side, there is that big news that was announced last year, with Microsoft ditching IE old versions officially on january 12, it will be on tuesday next week. IE 11 would become the only supported version. A bold but welcome move. Maybe it will help adoption of JS recent native APIs. I suspect that if IE dies, jquery will not make any sense anymore as the JS stack will be more consistent then. But maybe I’m wrong, that’s just an intuition. And the end of support doesn’t mean there will be an instant extinction of old IEs, it may still take some more time.


Moving to Hugo

As I love website pre-generation concept I have been using Jekyll and Octopress quite a lot. But now I wanted to give a try to Hugo.

Also, I have had various spaces of blogging in the past few years, so I thought I should just recenter everything in a unique place. There was an old blog on tumblr because I wanted to see how it was made. Then I had a period of time where I was publishing tips on the Faria Devtips website, which is down now. Then I also publish some rants every week on the Greenruby newsletter.

Only the last on is still active, so I will cross-post things from there to here, which should not be too hard as they are both markdown.

The first impression of Hugo is that there are still a lot of small weird things. But in some ways, I’m kind of happy about it, I guess I will try to fix some of those, that will be an occasion to play a little with golang.


Just met Hugo

Some weeks ago I was talking about Octopress. I think pre-generation of websites is a very sensible approach. And I heard about Hugo for some time now. It’s like a cousin of Jekyll but writen in Go. The author of Middleman (another site generation engine) confessed in a recent podcast that he would try the Golang way if he had to start from scratch today.

I got interested into Hugo mostly because one of the side projects I’m working on. It involves a bunch of people that run on windows. Having a binary that runs everywhere is a big plus for a gGo solution. Installing ruby is possible on windows, but not really for noobs afaict.

Also, I want to check more Go projects. I have been playing in and out that language for a while now. Version 1.5 seems really great. So I upgraded my gvm and installed the thing. Well, I could havce just used the Hugo binary, but where is the fun in that?

My first impression is very comfortable. It took a lot of the principles form Jekyll. But it seems to have some extra options and concepts that may be a little more advanced and seem very promising. The theming system is especially cool. I will probably first port my own blog under Hugo before porting my other project.

As a matter of fact, that’s a while I’m considering that I never feed my blog, but I should copy the rants I write here in there. It can be fun to add a rake task in the greenruby publication process to also add a page in a nearby hugo repo and publish it at the same time.


Octopress 3 and other thoughts

I’m currently involved in a community project and I installed a wordpress. From time to time I get one up to see how it evolves. But really this thing is not to my taste. To much trouble for making simple things. I reckon it can be useful for people with no technical knowledge but then they are going to mess up everything. The technical advisor still can’t be avoided.

So because now I saw a recent wordpress and didn’t like it more than the previous attempts, I will give a try to the new octopress 3.0. The octopress author explains that he’s been doing it all wrong and now on version 3.0 he gets back to sort of a collection of gems that plug into jekyll. I kind of like the idea.

Well to be honest I was also tempted to give a try to phoenix, but I know jekyll already and I don’t have that much server resources for that community project. Static web always have had my preference. But the idea behind Phoenix is appealing. Like any new project it includes the new things and don’t have to bother about legacy. The channels ideas, creating a stream between client and server, sounds very appealing.

But to get back to why I will prefer jekyll over wordpress, is that my contributors are a mess. They don’t care about styling, they copy-paste random html all over the place and the final look is totally inconsistent. My hope is that markdown would limit the possibilities of making a mess. But then I will have to propose them the github edit, as a backend, unless I cheat and use etherpad-lite as a pre-production backend.

That etherpad-lite thing is amazingly simple, I used sometimes and making it accessible behind a single password for everybody makes tings pretty direct. But totally unsafe, I reckon. I will probably have to write some kind of tool for managing the publication workflow. Hmm, that sounds like fun. If you ever had the same kind of adventure, please share with me :)


Make it static

Damn omnivore

Last week Green Ruby was sent with a delay. For some obscure reason my publication was blocked by Omnivore the automated fraud detection system from Mailchimp. My account was instantly blocked and it was pending a human review. Of course the human review made it clear that the publication was clean but it took 2 days and I still don’t know why this omnivore beast went mad at me.

They declare it’s getting smarter everyday, but really, we are still safe. The reign of the intelligent computer over the human species is not close yet.

Make it static

Dynamic websites are great. But that’s a long time I wonder about the trade-off. If you update your blog every day, and have 500 visits, your dynamic setup is useful when you edit, and it’s a cost for each visitor. There are so many web applications that could be more clever about it. Especially that now the computation is going more and more client side.

Static pages have a really unbeatable response time, their security is really reliable, they are low dependencies and easy to deploy with a rsync.

When I get to think about making a new website, I always ask myself if it’s an application or a website. For sure some kind of applications are computation intensive. Making it all dynamic could make sense. But frankly, if it’s a website, it can have some fancy dynamic features without a huge dynamic setup.

I have seen so many websites made with php, mysql, 5 tables and 20 entries in each. Such site should have pre-generated content, data available as static json files, as a bit of js to make the magic happen. If there is a lot of data, fine, an API server makes sense.

So next time you gotta prepare a website, ask yourself how easy it could be to generate it and use tools like Jekyll or Middleman. Or you can even handle things with custom rake tasks (like I do for Green Ruby website), that’s not that hard. It’s a matter of cyberspace ecology.