As you may know, Apple doesn't allow creation of iOS applications just like that. Especially under Windows. It's somehow a complex process, which requires several steps in a specific order. However it is still possible and you can do that without Mac.
You've probably heard about ToDoMVC project. It's same ToDo application made with different frameworks. It's interesting how the same problem is solved by different programmers following different concepts. This article is about making the ToDoMVC application with AbsurdJS.
Before a couple of months my first book Node.js Blueprints was published by Packt. There are a couple of reviews in Amazon about chapter two. It’s about Express. One of the most popular frameworks in the Node.js ecosystem. The book mentions version 3.0 but the truth is that the code samples are for version 4.0. I feel that I still have to point out the differences and mark these parts of the chapter that are not valid for the newest version of the library.
The setup here is available at GitHub here.
Half an year ago I published A modern React starter pack based on webpack. The starter provides the basic tooling around React. However, I noticed that very often I need even less stuff than that. That’s usually when I want to hack something quickly. In this blog post we’ll see what’s the bare minimum to work with React.
Long time I was searching for a good front-end framework. Framework that will help me write scalable and easy to maintain UI. Even though React is just a library for rendering it comes with so many benefits that I can easily say “I found it”. And like every thing that I use a lot I started seeing some patterns. Techniques that are applied over and over again and I see in the code of other developers. It’s time that I start documenting, discussing and sharing these patterns.
On my machine I have four applications always open - VSCode, Chrome, iTerm and Slack. I spend most of my time in Chrome and VSCode. My editor is full with awesome extensions and I feel pretty good there. What I am doing for the browser is making sure that I have fewer tabs open and install only extensions that I really use. One thing though I can achieve so far. I can't find the perfect new tab extension.
Long long time ago in a kingdom far far away there was an app. The app was supported by the well known React and Redux families but there was a problem. It was damn slow. People started complaining and the app had to do something. It had to deliver its content quickly so it provides better user experience. Then the server-side rendering was born.
I'm using Git and GitHub in particular a lot. And when I say a lot I really mean all the time. Recently I tracked a week of work and found that 62% of my working time goes into code reviews. Sometimes I'm checking out a branch locally and trying stuff but really most of my time goes into github.com. I spent some time analyzing why the code review process is so time consuming for me. I identified couple of reasons, made a tool and changed some of my habits. In this article I'll show you how I improved my code review speed and lower the time to 38%.
Recently I stumbled upon on an interesting bug which reminded me what is actually happening with my components when React is rendering them.
87% of my readers are using Chrome on desktop. This means that I have the luxury to care less about performance. However I just recently found that this blog has 56 (out of 100) points on Google's pagespeed test. That's not good. The report says that my Disqus comments are blocking the main thread for ~900ms. I want comments on my blog but I also want my users to reach to content as quickly as possible. So, after so many years using Disqus I decided to break with it and use something else.