When you have a hammer, everything looks like a nail they say. That’s true to an extent, but actually some patterns are so generic that both problems and solutions seem to be the same. If you think otherwise just let me to tell you a story of one fast food restaurant.
There are some habits that I developed during my life that sometimes give me pure moments of joy. The reason that happens is mostly due to the fact that I don’t know exactly what I get and I don’t do it to achieve something, it’s plain curiosity.
All the points below summarize the things I enjoy using in Common Lisp and are not especially the ones preferred or recommended by community. Also proof reading showed that many of the examples were already mentioned earlier, but I still think it’s good to have them all in one place for the reference. Here you go.
With a database of raw posts at my hands, I started thinking about ways to implement the merge. First and foremost I had to identify which posts actually had to be merged. This is trivial with missing posts, but for existing ones I had to have something to compare them to, and since I had raw posts from the server with the server timestamp I had to get server timestamp for all existing posts and update it for any posts that I wanted to change.
All the functionality mentioned before was quite complete and I used it constantly for a year or even more. There were two drawbacks, however:
There are a lot of different bits related to the client that were pretty fun to solve, especially in order to get git-like behavior, but nothing of that matters if we cannot communicate with the server, so let’s start with that.
Once I decided to sit down and write a perfect blog client for me. Since it was not just about the result but also about the process I chose a language I enjoyed the most and this is how it ended up being written in Common Lisp. I didn’t think I’d get that far and I’d like to share my experience in the process along with all little details that I had to go through during the implementation.
Ouch: This post was supposed to be published back in September ‘17, but I saved it in a future date. Here you go, anyway.
Since last summer I decided to invest some time into learning common lisp and wasn’t disappointed. Certainly, the language shows it’s age and there are some issues with documentation and libraries, but the benefits are so great that it’s hard to return to usual languages of choice.
I used Radiant player for a long time and didn’t have any complaints till the moment most of Google Music interface stopped working well with the app. I checked bugtracker multiple times and no one raised similar issues. Feeling myself weak in Objective C land I didn’t have any desire to go and fix things myself and, as a consequence found myself opening GM app in the browser.
Though I have some experience with clojure which is lisp I always had a feeling that this experience is incomplete without trying other dialects, especially common lisp. This post describes my experience on starting with this language.
There are many trendy things in wht wild and perl is definitely not one of them. Many blame it to be write-only, and it really has some ugly parts, there are things where it definitely shines. There are lots of parts that make data juggling easy.
Data rules the world, right? Vast amount of information can be used not only to extracts some insights from it, it can be a weapon or a timebomb depending on the circumstances. Bad news for ordinary people is that they rarely have access or own information, they mostly ask for it. What if one refuses to answer?
After working many years in the frontend development area I really got used to technology which led to some kind of blindness to the errors that can happen, I don’t see certain kind of errors anymore just because I got the habit of doing things certain way and it doesnt (usually) get me into trouble.
This December a big chunk of my free time was spent on solving quize from Advent of code challenge. While I wasn’t anywhere amongst the leaders it was a pure joy to see how clojure helps to gradually build solutions without constant switching between the editor and console.
One of the things that I love to do the most is to take a complex system and start digging through it to discover some subtle details that reveal how the system really works. This writeup is about one of recent tasks where I wanted to understand how to accelerate execution of some arbitary code for node. I coudn’t come up with better algorythm to solve the task but suspected that the code itself could have been written in a better, more efficient way from interpreter’s point of view.
This summer I saw some videos with FPV races that were so awesome that I decided that I want build my own drone for racing.
A while ago I decided to implement something close to the real world in clojure. The easiest way to do that was to take some existing non-toy project and try to replicate it. My choice was to reimplement parts of carbonapi and the result is called clj-carbonapi. The overall experience was so good that I decided to write a blog post with finding and pitfalls encountered during the implementation.
Peter-Paul Koch wrote a post a while ago, and there was a follow-up from Nicholas Zakas. While reading the first post I found myself almost agreeing with the author. Almost, because I really think that the amount of new features is not the problem for me and I can explain why, because the reason is very simple.
This winter I studied the fascinating course about image and video processing by Guillermo Shapiro and decided to make my own javascript library with bells and whistles and also try a few approaches to code that were not battle tested by me.
I decided to write down my own thoughts and conclusions from the course “Learning how to learn” as a final project. My own part will represent some ideas that I have and that provide more context to the course on my opinion.