Hello everyone! Long time no see.

Time is a curious entity. It's omnipresent, governing every aspect of our lives, from the mundane to the profound. In this digital age, our perception of time has transformed. We're constantly racing against it, marking moments with precision, and reflecting on its passage. Enter ATimePal, your digital companion designed to navigate the intricate web of time. Whether you're setting a 5-minute timer for a quick task, recalling events from 6 months ago, or charting out plans 3 weeks from now, ATimePal is here to assist.

The Genesis of ATimePal

Every creation has a backstory, and ATimePal is no exception. The journey began with a simple idea—creating a tool that transcends traditional timekeeping. But, as with any venture, the path was dotted with challenges.

The first hurdle was technical. How does one build a platform capable of hosting thousands of pages without compromising speed or user experience? After much research and countless cups of coffee, the solution emerged: Next's server-side generated pages. This approach ensured ATimePal could scale without limits, accommodating every user's query, from setting a 100-second timer to reflecting on events 10 weeks ago.

But the challenges weren’t just about coding. Venturing into the realm of SEO was akin to stepping into a vast, uncharted territory. With Ahrefs as the guiding star, the process of keyword discovery and optimization began. This research was pivotal in shaping ATimePal, ensuring it resonated with genuine user needs.

Beyond Just Timing: A Dive into Past and Future

At its core, ATimePal is more than just a timer. It's a time capsule, a forward-thinking oracle, and a reflection tool—all rolled into one. Consider this: How often have you wondered about events from 12 weeks ago? Or felt curious about what life might look like 9 months from now? ATimePal doesn't just provide answers—it paints a vivid picture, often sprinkled with fun facts and insights.

For instance, if you're looking to venture 2 days into the future, ATimePal might surprise you with snippets about light's journey during that period. Or if you're reminiscing about a particular date, you might discover intriguing numerical significances attached to it. It's this depth of interaction that sets ATimePal apart.

Making Every Second Count

Life is a mosaic of moments, each second contributing to the larger picture. Whether it's the adrenaline rush during the final 60 seconds of a game, the serenity of a 4-min meditation break, or the anticipation building up 8 hours before a significant event, ATimePal ensures you're attuned to every tick.

But it's not just about the immediate moments. ATimePal offers a window to the past and a telescope to the future. Want to relive memories from 15 minutes ago? Or chart out milestones 18 hours from now? With ATimePal, you're not just a spectator—you're an active participant in the dance of time.

User Experience: A Cozy Digital Nook

Amidst its myriad features, what truly endears ATimePal to its users is its ambiance. The platform is designed to be a digital sanctuary—a cozy nook where users can explore, reflect, and plan. The interface, with its warm hues and intuitive design, invites users to linger, making every interaction a delightful experience.

Whether you're setting a timer for a brief interval, like 20 seconds, or embarking on a longer journey 5 years from now, ATimePal promises a seamless and enriching user experience.

Time: A Universal Constant

Time has always been a universal constant, shaping civilizations, narratives, and personal stories. It's the silent observer, marking every milestone, from the monumental to the minuscule. Yet, in our modern lives, it often feels like we're racing against it, trying to squeeze productivity from every 25-minute interval or stealing a few moments of reflection about life 6 weeks ago.

With ATimePal, the aim was to create a bridge between the relentless march of time and our human need to interact with it. The app is not just a tool; it's a companion. It's there when you need to set a timer for 2 minutes to steep your tea perfectly. It's there when you want to know what time it was 30 minutes ago during a crucial event. It's there when you're planning an event 10 weeks from now and need to look ahead.

The Beauty of Moments

Every moment holds a story. Even the seemingly mundane intervals, like 60 seconds or 4 minutes, can hold profound significance. ATimePal recognizes this and celebrates every tick and tock.

Consider the moments of anticipation, waiting for a loved one's call 15 minutes from now. Or the moments of reflection, pondering over decisions made 9 months ago. Time, with all its ebbs and flows, is beautifully intricate, and ATimePal is designed to help you navigate it with grace.

The Road Ahead

The digital age is ever-evolving, and so is ATimePal. As we look 3 weeks into the future or even further, the commitment is to continually refine and expand. There's a promise to ensure that every user, whether they're reminiscing about the past or planning for the future, finds value and connection.

Conclusion

Time is an enigma, a constant that's both tangible and elusive. And in our fast-paced world, tools like ATimePal serve as anchors, helping us make sense of the past, present, and future. From setting simple timers to diving deep into the intricacies of moments gone by or those yet to come, ATimePal is more than just an app—it's a journey through time. So, as you set your 20-second timer or ponder events 12 weeks ago, know that with ATimePal, you're never alone in your temporal adventures.

This series (yes, it will be a series) is taken from the paper I have written in the university. It is a report on the process of building “Хочу в ТГУ” application.

In case you want to have a look at the application… all of a sudden it is only available in the Russian language now. If this doesn’t scare you, you may find an iOS version here and Android version here.

I decided to publish the text, first of all, since my paper was highly scored by four academics who had read it. I would also like to thank my supervisor Lidia Ivanova who has pushed me to make it much better than I would make it myself 😃.

I also have modified text a bit. Mostly changed dry and dull formal writing to something more alive.

The app

Tomsk State University (I will mostly use “TSU” abbreviation here) has a special website with many important and helpful information for enrollees. With information about the application process, available programs and so forth.

And it’s also had a native application, but it did not support updated API, which caused many usability problems.

And, as I had an internship at university (where we had to work on real-world projects😃), I have been given the task to develop a new application😃.

Taking into account the fact that the application will be distributed to the Android and iOS marketplaces, the goal was to develop a cross-platform application.

To achieve this goal, the following things were done:

• Research of the existing solutions.
• Application design.
• Implementation.

I will drop section with the research of the existing solutions out as it doesn’t bring any important information.

About

This article is intended to show the formal application design (a.k.a analysis) that is done to clarify:

• What functionality application should realize
• How the application should be created
• What tools should be used to create it
• It’s discussed how to architecture the application
• Declared what views it will have
• Entities that will be used and their relations are declared too

Requirements

After reviewing existing applications and receiving requirements for this application from the university stuff, functional and non-functional requirements were formed. This is a functionality that a complete application should provide to the user.

Functional requirements:

To show the functional requirements, UML Use-Cases diagram was drawn:

Non-Functional requirements:

1. The app should use the REST API to retrieve app data from servers.
2. The app should cache opened news.
3. The app should save data about government exams, so the user does not have to enter it twice.
4. The app should run on Android and iOS mobile operating systems.

Problem Domain Model

To represent the business domain(what is that), corresponding diagram was made:

Here Question entity represents fixed question-answers loaded from the server and shown to the user on the screen, while PresonalQuestion represents an entity that is filled by the user-provided data(through the in-app form) that is sent to the server later on.

Used technologies and tools

Considering that the app should run on both Android and iOS operating systems, cross-platform development framework was in favourable choice to native development.

After reviewing two front-edge solutions, React Native and Flutter, the Flutter framework was chosen for the development. Let us go through different cases and see why.

• Flutter is an open-sourced SDK created and supported by Google and was initially released in May 2017. Flutter is using the Dart language, which is also developed and supported by Google. Meanwhile, React Native was developed by Facebook and initially launched in 2015. In React Native JavaScript is used as the primary development language.
• Dart in Flutter features ahead-of-time compilation for Flutter application run in release mode which results in self-contained and native executable code running on iOS and Android. JavaScript features just-in-time compilation and which is translated by React Native framework to native elements through Bridges on the app run. Given that the Flutter code translates into machine code and run directly on the phone it usually provides better performance than React Native that needs to translate JavaScript to native platform elements that would be translated to machine code.
• All UI in Flutter application is constructed using Widgets – components in the form of classes that describe what their view should look like given their current configuration and state. In React Native UI constructed using HTML like components and styled with CSS. In my view, the Flutter approach to constructing the application is more closer to experience seen in native Android and iOS development. While React Native take major from React – the web development framework, those it will better suit developers with web development background.
• In debug mode Flutter also features a just-in-time compilation, like React Native, that is used by “Hot Reload” feature. It makes it possible to update the application and rebuild a widget tree without completely reloading the application and losing current states of the widgets.
• Additionally, Flutter provides better development and profiling tooling.

Development tools

Regarding main development, everything happened in Visual Studio Code editor from Microsoft. It allows to develop applications for Flutter and have a fast and minimalistic interface.

Additionally, Android Studio IDE from Google and Xcode IDE from Apple were used for working on platform-specific areas like creating and running Android Emulators and iOS Simulators, for setting applications ids, names, icons, splash screens.

Flutter plugins

In the application additional open-source libraries were also used to cover development needs:

1. bloc – state management library used for building the architecture of the application. This package will be discussed in more details in the Architecture section and in the next article on implementation, which is coming soon.
2. retrofit – dio client generator used for automatic methods generation that realizes calls to server API and converts JSON received in response to Dart classes.
3. hive – NoSQL Database used for storing news and selected subjects. This DB will be discussed in more details in the Data Storage section.
4. flutter_screenutil – library for adapting sizes and fonts to different screen sizes. With this library, UI elements sizes and text fonts get correctly adjusted for all possible screen sizes, which are not always achievable using build-in logical pixel sizes.
5. get_it – Service Locator library used for accessing database instance from application BLoCs.
6. flushbar – library for making customizable and variative notifications in the application.
7. table_calendar - library for displaying events on the months’ calendar.

Architecture

Flutter framework does not have build-in architecture system, nor it provides one best-practice solution or approach. Developers should choose architecture solution by themselves from quite a significant amount of approaches that could differ a lot.

Before choosing final architecture, three approaches have been reviewed, namely: Vanilla, BLoC and MobX. Here is a short overview:

1. The vanilla approach represents an application where everything happens in application widgets. All logic, data operations, manipulations, UI encapsulated together. This approach is fast and easy to implement and follow for small applications with very low or no business logic. However, for more significant applications with different business processes, this results in huge classes that are hardly maintainable, updateable and testable.

2. BLoC approach put much more structure into the application compared to the vanilla approach. It separates an application into three layers: presentation, business logic, data (this is also discussed in more details next section). Each layer is picked out by the responsibility area and limited to what it should do in a concrete area(UI, business logic…).

   Also, BLoC makes the use of Dart build-in reactive programming solutions, which helps to build a fast and reactive app with relatively easy implementation. An example: widgets subscribe to state stream of the BLoC and UI updates automatically as soon as the new state with data is available(which is loaded from the server, for example).

   Thanks to the separation of responsibilities, it is easier to test and change different parts of the application.

3. MobX – this package and approach resemble BLoC in a reactive programming approach in connection UI and data. However, it puts a bit less structure on responsibilities separation and specializes mostly on reactive data delivery. Though, MobX also present separation of business logic and data operations from UI, but lack the level of testability of BLoC.

After the analysis, the BLoC approach has been chosen for the architecture. It’s one that suite well for the app that fetches a lot of data from the servers and wraps most of its logic around it.

Package Diagram

To represent the architecture and show “layering” in the application UML package diagram was drawn:

Each package in the layer poses behaviour peculiar to only this layer.

As can be seen, there are three main layers:

1. Presentation – this layer contains everything that would be shown on the screen to the user:

   • UI Widgets – widgets that show the user a GUI, present him data loaded from the server. They do not perform any operations on data and only show what they have received from the Business Logic layer. Or collect data and pass it to the Business Logic layer.

2. Business Logic – this layer contains the business logic of the application. Elements in this layer are responsible for the correct work and behaviour of the application. Here are the packages that are responsible for that:

   • BLoC – classes that contain all the logic of the application. These classes organize data loading from/to server, saving/loading to/from a database. All the manipulation with the data mostly encapsulated here. It also provides data to the Presentation layer.
   • Models – are classes that represent the problem domain and used for transferring the data between layers.

3. Data – this layer represents all objects that provide data to other parts of the application:

   • Hive – DB that is responsible for data saving on the device.
   • ApiClient – package that organizes data loading from/to the server using Http protocol.

There are also additional packages that do not fit into the above layers:

• Utils – package that contains additional supporting classes. For example, for a time conversion to special String format.
• On-Device Stored Data represent raw byte data stored on the user device by Hive DB.

State Diagram

For showing application screens and navigation between them, several UML State diagrams were drawn:

After launching the application Info Screen (above picture) opens. Here user can read news and open them in more detail or view stories.

If the user wants to use a calculator to search for different courses, he opens the corresponding screen (above) using the bottom navigation bar. On the screen open corresponding BLoC check if there are saved subjects for the calculator. If subjects persist in DB, they are loaded, and Program Preview screen opens automatically. If no, the user sees a welcome screen that asks to select subjects for the calculator on Subjects Choose screen, after that Program Preview screen opens.

For getting answers for different questions, the user can open FAQ screen (above) using the bottom navigation bar and browse some ready-made answers and questions. For example, read Undergraduate Frequently Asked Questions. If the user has a question that is not covered there, he can ask his personal question on Personal Question screen.

To find out upcoming events, the user can open the Calendar screen using the bottom navigation bar and browse the monthly calendar with events. If the user wants to read more details about the event, he can view them on the Event screen.

If the user wants to see his rank for enrolled courses, he opens the corresponding screen (above) using the bottom navigation bar. On the screen open corresponding BLoC check if there are saved user credentials. If user data persist in DB, they are loaded, and user rank is opened on Ranks screen. If no, the user sees a welcome screen that asks him to fill his full name on Name screen. After that screen with ranks opens.

Also, the user can close and exit application being on the first screen of the type.

Data Storage

As there is a need to cache some data loaded from the server application needed a database. Since the primary usage of the database is lying on news saving and loading them on every app launch, speed was an essential factor. With this regard in mind and the fact that data that would be stored has little or no relations (diagram below), Hive DB was chosen. It is a NoSQL key-value database that works incredibly fast compared to SQLite, the classic mobile relational database. Additionally, it is much faster in implementation compared to SQLite since it has needed queries build-in and require less management and provisioning.

Wrap Up

These are what have been done to ensure a fluid start of application implementation in code.

Next article on how it all was implemented is running in process… stay tuned😉.

For me, it didn’t look well. Especially inline code. So I went over to style it a bit.

Highlight JS

First of all, I checked how I can highlight code inside code blocks. The markdown-it package that I use for Markdown parsing contains a special option for this.

I have tried setting highlight using the provided example, but something didn’t work out, and I also found markdown-it-highlightjs plugin that simplifies everything.

You just set it up as written in the docs and specify a style that you want to use for highlighting as global CSS.

That’s how it’s done with me in Nuxt. In the nuxt.config.js:

export default {
  /*
   ** Global CSS
   */
  css: [
    {
      src: "~/node_modules/highlight.js/styles/github.css",
      lang: "css"
    }
  ],
}

As you may see, I have chosen the GitHub highlight style. It worked best with the background I decided to use for code blocks.

The whole list of available styles you may find here. And here is a helpful page where you can check the look of each available style.

Typography

Next part was setting everything up in typography plugin.

First, I set code block background to lightest grey I had in the palette, so code block would be highlighted, but won’t stand out as much as default one. You can see how it’s done in pre related setters in code I’ll provide below.

Second, I changed the look of the inline code. For this code styles had to be modified. I made the lightest grey background on the code text too with red colour for the text itself. And I also removed ` symbol at the beginning and the end of inline code.

Here is the full code that I used in tailwind.config.js:

module.exports = {
  theme: {
    colors: {
      grey: {
        100: "#F5F7FA",
        1000: "#1F2933"
      },
    },
    typography: theme => ({
      default: {
        css: {
          pre: {
            color: theme("colors.grey.1000"),
            backgroundColor: theme("colors.grey.100")
          },
          "pre code::before": {
            "padding-left": "unset"
          },
          "pre code::after": {
            "padding-right": "unset"
          },
          code: {
            backgroundColor: theme("colors.grey.100"),
            color: "#DD1144",
            fontWeight: "400",
            "border-radius": "0.25rem"
          },
          "code::before": {
            content: '""',
            "padding-left": "0.25rem"
          },
          "code::after": {
            content: '""',
            "padding-right": "0.25rem"
          }
        }
      }
    })
  },
  plugins: [require("@tailwindcss/typography")],
};

All the modifications are laid in typography part.

Result

With all this set, code in blog posts now look like this:

Yeah, you already have seen this, but in case something will change 🙃.

Check previous ones if you haven’t already:

1. Image optimization service for Netlify CMS and Nuxt - about how I have chosen to use Netlify Large Media for that.
2. Fixing Netlify Large Media install - about my terrifying experience setting up Netlify Large Media.
3. Optimized image loading in HTML and Markdown – about using all it in the code with images set in HTML and Markdown

In this article, I will go through the speed improvements I achieved.

I have run speed tests using Google PageSpeed Insights.

For testing, I chose these pages:

1. Index page with my work showcase.
2. Bio page with one big image of me.
3. Blog article with many pictures.

Let’s not delay the inevitable and check the optimization results:

Not bad as for me. It wasn't so bad before but got better.

On Google PageSpeed results

I also would like to mention one important thing I noticed while doing tests:

PageSpeed test could give really different results. It could show +-10 points from run to run. Don’t know what it depends on, but, for example, I was getting results as 88-90-91-80 on the absolutely same page. So craving for 1 or even 5 points is not so statistically significant. You should better focus on moving through categories of 10-20 points.

PageSpeed test could give really different results.

It's better to focus on moving through categories of 10-20 points with it.

But anyway let’s check what optimizations led to better speed results.

Main page

The main page contains three images with pretty different sizes, ranging from 330 kb to 1.22 Mb.

After loading optimized images from Netlify Large Media, I got small speed improvements.

Here is the detailed breakdown of image size differences before and after optimization:

1. Was 448x894 pixels image with a size of 330 kb. Became 250x499 image with a size of 140 kb.
2. Was 906x2000 pixels with a size of 422 kb. Became 250x552 image with a size of 96.1 kb.
3. Was 869x2000 pixels with a size of 1.22 Mb. Became 250x558 image with a size of 190 kb. Totally, 1.5 Mb of fewer data to be now loaded.

Also, 2 and 3 images are now lazy-loaded(I described what is this here).

All this resulted in moving from 99 to 100 points on desktop and from 93 to 96 on mobile. Should be enough for living.

Bio page

The main problem with the bio page is that it contains one photo of me.

With an original resolution of 1330x1330 pixels, its size is 2.14 Mb. And this results in a score of 84 on desktop and 90 on mobile. I’m pretty surprised that it loaded faster on mobile 🤔.

After loading the optimized image with the resolution of 250x250 pixels and the resulting size of 114 kb, desktop speed bumped to 100. Could not be better! But on mobile it stayed the same 🤷‍♂️.

Article page

Article I chose for the test contains 9 images with sizes ranging from 34 kb to 845 kb.

On mobile, it had the worst performance out of three test pages - only 59 points. This had to be changed. While on the desktop everything was pretty fine.

As I have written in the previous article, on blog pages images are usually loaded with 600 pixels width and in rare cases with 300px width, when the screen width is around or less than 200 pixels.

Loading optimized images increased score a bit on mobile. I have been getting something like 70 points on good test runs. Adding lazy loading at the same time bumped test scores to 80. Not the green score, but not as bad as it was. On a desktop, it became even 99.

Conclusion

Image optimization on the web is essential since images take a significant part of the page size. It should be especially crucial on images heavy websites. Even with my site, where aren’t a lot of images, I got page load speed improvements.

So answer to the raised question is Yes, doing image optimization on the website is worth it.

Nevertheless, setting up the image optimization service and finding the way to use it with images set in Markdown was a daunting task. Still, I don’t have any regrets I went through this.

If you build your site using the similar stack (headless CMS, front-end framework), feel easy to check what I have run into to give it a better and easier go.

Check previous ones if you haven’t already:

1. Image optimization service for Netlify CMS and Nuxt - about how I have chosen to use Netlify Large Media for that.
2. Fixing Netlify Large Media install - about my terrifying experience setting up Netlify Large Media.

In this article, I’m going to talk about how I implemented all this on my website. What worked and what didn’t.

Images in HTML

Let’s start with the images set using HTML.

This is how it’s done with me:

<img
  src="/img/sample_image.png?nf_resize=fit&w=250"
  loading="lazy"
  alt=". . ."
/>

Loading optimized images from Netlify Large Media

I add ?nf_resize&w=250 to load an image with a width reduced to 250 pixels and proportional heigh.

Why I chose 250px? I checked what is the maximum width of the particular image when it’s rendered and set the width accordingly.

On my site, images usually are shown in different sizes. For desktop browsers, it’s fixed width. On mobile, it’s wired to screen width, so it could range from 30px to 236px (something like this), so I simply chose 250px since it never gets bigger than this.

Additional parameters that can be specified on image request from Netlify Large Media you may find in docs.

Lazy loading

Adding loading="lazy" say that browser should load an image only when it’s close to the viewable viewport.

When I didn’t set that at the beginning, the page loaded in the following way: on page open, browser paints the first HTML and starts loading all images used on the current page and until it finishes page are shown as loading. If the page contains many pictures, that take time. Sometimes a lot.

When you set loading="lazy" browser loads only images that are in the viewable part of the page and in the area of 1250px-2500px down it (doc). At least on Chromium browsers it should work this way.

So, yeah, it could speed up page load a lot, since loading first 3 images and then others, as needed, is faster than loading more at once😉.

However, I didn’t set this for the first images on the pages, as advised officially here. These images are anyway going to be loaded on the page open🙂.

Trying srcset and sizes

I also tried to do responsive image loading with the following code from Mozilla:

<img srcset="path_to_image.png?nf_resize=fit&w=180 180w,
             path_to_image.png?nf_resize=fit&w=250 250w"
     sizes="(max-width: 400px) 180px,
            250px"
     src="path_to_image.png?nf_resize=fit&w=250"
     alt=". . ."
/>

As from code, it means that on screens with a width up to 400 pixels browser should request an image with this parameters: ?nf_resize=fit&w=180 180w. Hence with a width of 180 pixels. While on screens with a width of more than 400 pixels, it should load an image with this parameters: ?nf_resize=fit&w=250 250w. So the width should be 250 pixels.

But these didn’t work.

When specifying sizes in the percentage of vw (viewport), everything works, as you will see later on with Markdown images. But with px specifications nothing worked. Images were always loading with this parameters: ?nf_resize=fit&w=250 250w🤷‍♂️.

After playing with it for some time, I understood that I could simply leave it with one ?nf_resize=fit&w=250 250w parameter. As I had before, like this:

<img
  src="/img/sample_image.png?nf_resize=fit&w=250"
  loading="lazy"
  alt=". . ."
/>

My images become really responsive on mobile, and figuring out correct vw for different layouts is a considerable pain (at least for me).

I have also downloaded images to compare their sizes. 250px one was 114 kb, where 180px one was 63,3 kb. Quite twice a difference, but after running Page Speed tests with 180px image, I didn’t see any improvements🤷‍♂️.

Loading optimized images from Markdown

Doing all this optimization for blog posts is a bit more complicated.

All my posts are written in Markdown and gets converted into HTML by markdown-it plugin.

Markdown language has some specifications and limitations on how images are described. Here is the structure of the image specification: ![Alt text people will see if picture can’t be seen](https://link.of/image “Title to show under the image”). Not so many things we could specify. Luckily we can do a lot of modification on how Markdown is translated to HTML with the additional markdown-it- plugins.

Lazy images

First of all, I found and added a plugin that adds loading=”lazy” to every image that is rendered by markdown-it.

Here is it: markdown-it-image-lazy-loading. ! If you are also planning to load optimized images by adding URL parameters to images, then wait a bit before adding it. There is a way to use only the plugin I will show next without the need to install this one. Just proceed to the next section.

After setting loading="lazy" loading speed of blog pages with many images rocketed. This attribute is really must-have. Check the results in the next article.

Images with srcset and sizes

Then I tried adding markdown-it-responsive package that should add srcset and sizes attributes to every image, but this didn’t work at all. I have been getting HTML rendering error and broken pages☹️.

After some additional search, I have found this plugin: markdown-it-modify-token. After checking it, I understood that it would work great, and I can do everything I need with it.

Some time and this code was born:

modifyToken: function(token, env) {
  switch (token.type) {
    case "image":
      token.attrObj.srcset =
        `${token.attrObj.src}?nf_resize=fit&w=300 300w, ` +
        `${token.attrObj.src}?nf_resize=fit&w=600 600w`;
      token.attrObj.src = token.attrObj.src + "?nf_resize=fit&w=600";
      break;
  }
},

By specifying srcset this way I’m saying to the browser: here is two images, with the width of 300px and 600px, decide by yourself what image to load according to 100% viewport width.

First I also added size attribute, this way:

token.attrObj.sizes = “100vw”;

But removed it after reading Chris Coyier article. It’s the default value for the browser, so no need to specify that additionally.

It works, but the behaviour is a bit strange (at least for me). When screen width is 200px browser load image with 300px width, but when screen width is set to 250px image with 600px width is loaded… I don’t understand that😐.

And again specifying sizes in px only led to 600px image to be loaded…

Here is code I have tried:

token.attrObj.sizes = "(max-width: 400px) 300px, 600px"

Ok, I will just leave sizes as 100vw and let the browser decide when to load what. Hope browser is smart.

As I wrote before, the usage of markdown-it-image-lazy-loading plugin could be dropped here for additional code in

modifyToken: function(token, env) {

}

Just add this:

token.attrObj.loading = "lazy";

Here, in case "image"::

switch (token.type) {
  case "image":
    token.attrObj.srcset =
      `${token.attrObj.src}?nf_resize=fit&w=300 300w, ` +
      `${token.attrObj.src}?nf_resize=fit&w=600 600w`;
    token.attrObj.src = token.attrObj.src + "?nf_resize=fit&w=600";
          
    // This will make all images loading lazy
    token.attrObj.loading = "lazy";
    break;
}

By the way, if you want to always load images with one size, just remove srcset setter. It would look this way:

switch (token.type) {
  case "image":
    token.attrObj.src = token.attrObj.src + "?nf_resize=fit&w=600";
    // token.attrObj.loading = "lazy";
    break;
}

As you remember, it’s better to have the first images without lazy load, but it’s a bit hard to do with images from Markdown. Additional logic should be written for markdown-it, and the time investment is not really worth it for me. Yes, there is a small drop a performance, as guys from Google say, but it won’t break the bank, I think.

That’s all I have done for better image loading on my site. In the next article, you could check page speed improvements I got. They are quite solid😉.

Here I will mostly use "NLM" abbreviation of Netlify Large Media for convenience.

First, using the docs, I installed Netlify CLI and authenticated. Then I went to the following docs on Large Media setup. After finishing the NLM installation on a PC without a problem, I set all files in static/img/ (where my site images are located) folder for tracking and pushed all that to Git. I fastly checked my GitLab repository and saw correctly looking pointers instead of images:

Then I checked that images are uploaded to NLM. Everything looked good. I was happy and went checking that everything is okay with the site after fresh build … and of course, it was broken. Not really broken(yet 😃), but with problems.

404 error on image loading from Netlify Large Media

After a correct build, images just didn't load on website open. I got baffled and dug into the documentation, searcing for possible missed step, but everything looked great. Many hours were spent trying to find the problem, and I even made an error that broke a project build(I would talk about this a bit later).

I was lost. So I decided to put a project off for some time. Before that, I just set deploy version to the last commit before changing to NLM. Luckily, you could quickly deploy every commit successfully build on Netlify, even old ones.

When I returned to the problem, I got an idea to check the browser console. I'm, as a mobile developer, used to getting all errors in IDE or in some additional services like Sentry or Crashlytics, and I didn't think about browser console, that could lead me to the error. Learning, learning the web… There I saw 404 error on the image fetch for the site with NLM. Some time searching and I landed on this.

So every problem was with this file: .git/hooks/pre-push. When I opened it, it was empty. After I runned git lfs update --force and git lfs push --all origin master then it got file filled with this:

#!/bin/sh
command -v git-lfs >/dev/null 2>&1 || { echo >&2 "\nThis repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting .git/hooks/pre-push.\n"; exit 2; }
git lfs pre-push "$@"

After this, I changed my site deploy version to the one successfully build with NLM enabled and saw all my images got correctly loaded on the website.

Oooooh. Good.

Nope. I also had another problem.

Netlify build error due to broken images

I couldn't build my projects anymore since I was getting Netlify project build error with a very unclear message:

Error: Could not find MIME for Buffer <null>
    at Jimp.parseBitmap (/opt/build/repo/node_modules/jimp-compact/dist/jimp.js:1:120817)
    at Jimp.parseBitmap (/opt/build/repo/node_modules/jimp-compact/dist/jimp.js:1:13252)
    at /opt/build/repo/node_modules/jimp-compact/dist/jimp.js:1:12318
    at FSReqCallback.readFileAfterClose [as oncomplete] (internal/fs/read_file_context.js:63:3) {
  methodName: 'constructor'
}
[error] 1
[error] (node:1318) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 1)
[fatal] 1

   ╭────────────────────────╮
   │                        │
   │   ✖ Nuxt Fatal Error   │
   │                        │
   │   1                    │
   │                        │
   ╰────────────────────────╯
 
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! Blog@1.0.0 generate: `nuxt build && nuxt export`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the Blog@1.0.0 generate script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /opt/buildhome/.npm/_logs/2020-08-09T13_27_15_157Z-debug.log

┌─────────────────────────────┐
│   "build.command" failed    │
└─────────────────────────────┘
  Error message
  Command failed with exit code 1: npm run generate

  Error location
  In Build command from Netlify app:
  npm run generate
  
  Resolved config
  build:
    command: npm run generate
    commandOrigin: ui
    environment:
      - NETLIFY_LFS_ORIGIN_URL
    publish: /opt/build/repo/dist
    

Everything I could understand from this is that problem was with images. But what, when and where…

When I first enabled NLM and pictures on the website didn't get loaded, I checked all documentation, and in Netlify CMS docs I saw this paragraph:

I understood provided Note in a way that I need to track all my .png files with NLM, or otherwise it won't work. That was utterly wrong since this was only related to the Media view in the CMS Admin console. So I mistakenly made track of all .png files in my project and pushed that to the repository. For reference, other .png files that I have not in static/img/ folder are website icons. And for some reason, these files didn't correctly load to NLM. I got site build fail with the error provided before. I got scared and tried to revert changes. But, but when you go for Git LFS and push tracked files to a repository, you have no easy way back 😬.

All that was before I decided to put the problem off and relax for some time. After I solved the problem with 404 error on image loading and returned to this one, I noticed that the images on my PC and in Git are looking strange. They weren't images, nor pointers. Some broken files:

�PNG

After some thought, I just changed that broken images for normal ones and of course stopped tracking all .png files, except ones in static/img/ folder. I pushed all that to the repository, and everything started to work! The project was built, and everything was working as it should.

"Finally!!!"- I wanted to say.

But that wasn't an end.

Problem with local images being pointers

I also had a problem with some of the images locally. In static/img/ folder, some of the images were normal ones(as they should be locally), while some of them were pointers. What? Pointers should only be in the repository on GitLab. While on PC they should be loaded as usual pictures. 🤬. When that (let's say a bad thing) will stop making problems? … Then I saw a warning in the GitKraken (Git client that I use). It said that the repository uses Hooks while it doesn't know where sh.exe file is located, so it couldn't function normally. I said okay, let's fix that. I didn't know if that would help, but anyway. I googled where to find sh.exe file on Windows, and everyone was saying that it should be in C:\Program Files\Git\bin, but I didn't have Git folder in Program Files… I thought okay, let's do the local search. After like 50 minutes, the Win search found +- 100 suitable files. After skimming thew them, I finally found where needed sh.exe file is located. If you are like me, here is the possible path for you:

C:\Users\username\AppData\Local\Programs\Git\bin\sh.exe

After I specified that path in GitKraken, it showed that there are files to pull. Or I by myself did the pull, don't remember for 100% unfortunately 🙁. The pull loaded all my images from NLM, and everything started to work as it should be on the local project!

Finally! Everything works!

Thoughts on Netlify Large Media after install

After the install, I had conflicting feelings. During the installation process, there were many problems. And the clearly opened fact that there is no easy way to revert everything back after you start using Netlify Large Media make me saying that using some other services(Cloudinary, for example) may be a better choice in most scenarios.

Speaking a little ahead, using the Netlify Large Media would help you to optimize images, increase website speed and help handle large-sized files in your repository.

But is this service worth possible problems? Now I hardly see its benefits over Cloudinary, and with the next project, I would rather go with Cloudinary. But, in the end, everyone needs to seriously weigh all pros and cons and make his own decision.

For this site, I will anyway now continue with Netlify Large Media. I anyway made an install, and it's working. And changing it to something else … not now for sure.

While building my website, I just used .png images when I needed them. They all were simply located in one of my project folders. And since I use Netlify CMS, images from articles were also stored the same way. And some of the images were pretty big; for example, my picture in the bio page was 2.14 MB. As expected, those pictures sometimes were loading for quite a long time. Not really good. And from the SEO view, site speed is important. So I also started researching how this is usually handled on the web. There are many resources on that topic, and I fastly found service named ImageOptim, which provides the great-looking solution. But it isn't free nor at least offer a free plan. I also read several articles on the topic and got an idea of how it is usually done.

Then I got back to Netlify Large Media. Overall, it looked sufficient for my needs, and long requirements & limitations list looked not so scary. This service use Git Large File Storage that, instead of storing exact files in the repository, stores files somewhere else and put pointers to the files instead of them. And pointers are just fraction of the size of original files. NLM handle the creation of these pointers and stores files on its own CDN's thus enable making transformations on the images when they are requested. While, when you work locally you still have normal images(they are preloaded by Git), not the pointers, so you keep usual easy of use. In the project, you still just specify a path to it, like this: /img/some_image.png. With this, on a local project, the original image would be loaded. On the deployed site, an original-sized image will be fetched from NLM too.

And when you want to transform image, you just add properties to the path, like this: /img/some_image.png?nf_resize=fit&h=400&w=400. Then you will get an image with size reduced to 400x400 px dimensions on the deployed site.

Sounds good, but NLM is not a straight forward solution and completely change the aspect of working with selected files in Git. This can lead to a terrifying time if something doesn't get to work. And a project could completely break, as happened to me, as you can find out in this article.

One more important point was the fact that Netlify CMS should also support selected image optimisation service. So it would be comfortable adding images on articles creation. On-time of writing, there were just three supported systems: Cloudinary, Uploadcare and Netlify Large Media. I also checked the first two.

From my first sight, I wanted to use Uploadcare. It looked so sleek. It's a distinct service where you could upload and store your images and can do a lot of operations on them. All usual ones, like cropping, resizing, adding visual effects, etc. and something more special ones like AI face and objects detection on images. Image fetching in the project is also made by URLs with additional fields for needed transformation, very like with NLM. However, you specify not the local-like image URLs, but the ones from Uploadcare domains, since all your files are completely there. I liked the look of Uploadcare so much that this wasn't a problem at all. Yeah, a great visual presentation has a really high impact on buyers wishes 😉. But when I finally reached the Price page…Well, it's definitely wasn't for me ☹. Basic plans cost over $100 a month, which is something for more big guys.

Great visual presentation has a really high impact on buyers wishes

The third player, the Cloudinary, is very similar to Uploadcare. But for me, it looked less pleasant nevertheless definitely working. The big plus of Cloudinary is that they had a pretty generous free plan. Actually, the price was shown like this: $17 - $0 🤔. I think this is just a marketing hack and the plan is always free, but who knows…

After some checks and thinking of what to choose, Cloudinary or Netlify Large Media, I finally went with Netlify Large Media. Mostly what bought me in NLM is that it's still kind of all-in-git approach and the fact that I would stay in Nuxt-Netlify ecosystem. Their pricing also looked pretty generous, and I would hardly reach the bar when I need to pay for it.

In my next article, you can read about my thoughts after installing Netlify Large Media and why I would rather go with Cloudinary next time.

I’m just starting out, and no one knows me, so when they land on my site and see only titles and texts, they have no idea if my writing worth their time. So how I would convey to people that I’m worth listening to? You may still say that through the words, by adding a cool headline, for example. And that 100% right. But here is one point. Even if they caught by the headline, they would need to dive into my article, absorb what I write, to understand if I’m worth their time. And that takes time. And I doubt many will do this. On the other side, visual “signs” are much faster deliverers in that regard. When a person opens a blog page and sees some good, interesting work, the creditability of the author increases. And I had something to show. That’s definitely not as great as mentioning that I worked at Google (well, Google has dark and light sides), or Basecamp, or created a multimillion company. But projects I have worked on are quite worth sharing, as I think. So yeah, in the end, I have decided to make a portfolio like main page.

Creating mobile apps showcases

Being mostly a mobile developer, my best projects are around that. And my first thought was to embed phones mock-ups with video of the working apps. That looked like a great idea. But after doing research on how to do it, I understood one thing: I could not find mock-up for the smartphone I have to show my games at work. I needed a physical phone to show games, yeah. Sadly, I had to put video-based showcases aside. Another way was creating simple picture mock-ups. That’s way easier. I already had screenshots for iPhone 11 and finding free mock-up was no brainer. After checking four different versions, I have stopped on this iPhone 11 Pro mock-up for Figma.

Doing the same with Android took much more time. Since I could not find mock-ups for my smartphone, I had to use an emulator to create screenshots for my games: Eyes On Me and Blink Killer. But in Android Studio the most modern-looking predefined emulator available is Pixel 3 XL which already looks a bit old. But I wanted to have something up to date. And even for it, I could not find free, suitable quality mock-ups for Figma. That’s the sad point about Android. Being so vast in phones and due to big differences of resources available for each, it could be tough to do such tasks. But I anyway needed an Android phone, since the games are present only for them. And I have decided that I would go with Google phone anyway. So to speak, as a tribute to the creators of the operating system 😃. Choosing Pixel 4, which is the newest Google phone, was an expected choice. Since there is no preprogrammed Pixel 4 emulator (no idea why) in Android Studio, I had to create a custom one. Luckily, with available specifications, I fastly created one and made needed screenshots. Finding Pixel 4 mock-up didn’t take hours, as I have found this perfect one. Some time in Figma and app’s images was ready.

Working on the page look and structure

After creating mock-ups, I arranged them in the way I planned:

But looking at the result, I understood that they look too … formal. Sadly, didn’t take a screenshot of how it was to show you. Anyway, I liked the details of the Pixel 4, the orange power button ... and I wanted to keep them … but mock-ups didn’t really fit well together.

Next idea that came into my mind is to create a carousel with the phones and text under each one. The possible result looked promising in my mind, and I fastly created example look. The result was not bad:

Making all that carousel to work and look well looked not the easiest task, but entirely possible, so I started looking for solutions. During that time, I remembered about one mock-ups plugin in Figma, and I also checked it out. It allows creating 3D mock-ups of iPhone 11 and Pixel 4 and rotating them in any axis. With no dought, I also created 3 new images with a bit rotated phones, loaded that on the page, and the result was even better than with carousel. This 3D images for my game apps made precisely what was needed – page started to look less formal, and the overall feeling was much better:

Next, I wanted to create a visual section for the games with fresh and fancy waves as top and bottom borders. I saw that on many great looking sites and wanted to have that too. After googling the theme, I have found great tool – Get Waves, that allows to generate customizable waves and easily embed them into the website with HTML. It’s easy as this:

<svg>
  This should be an top SVG wave taken form getwaves.io site
  <path
    fill="#fff3c4"
    ...
  />
</svg>
<div style="color: #fff3c4;">
  This is your section body
</div>
<svg>
  This should be an bottom SVG wave taken form getwaves.io site
  <path
    fill="#fff3c4"
    ...
  />
</svg>

And the final look:

Last part was writing and adding supplementary texts which took some time, but nothing fancy to tell about.

Creating an icon

When I found Get Waves site, I really liked its design. It was simple, clean, vibrant - great, to say shortly. And while checking the site, I also discovered Blob Maker, from the same studio. I played a bit with it and closed it.

After some time, while working on the main page, I got an idea about how I could create a cool icon for my site. Before I had the simple text “Nikita’s Blog” as an on-page icon and letter N as a favicon for the tabs. That did the job, but it still wasn’t looking great. So I thought: why not to generate a blob and put N letter in the centre of it? Simple but creative. I have made a bunch of blobs, and after comparing them all, chose one:

Added it to existing text, played a bit with text colour and sizes and got the final result:

Here is the old look for comparison:

Blobbing the site

After I made the icon, the idea of using blobs on the site has taken my mind.

I have changed my picture in Bio into the blobby form:

In the beginning, the first paragraph on the main page was a simple text where I have explained who I am and what I’m doing. Looking at it, I had conflicting feelings. It delivered the message I wanted to say but seemed a bit copied at the same time. And I wanted to change it, but all the approaches were no better. After some time, I got a thought that blob could also save me here. I generated one in indigo colour and added a lovely orange welcome message over it with some complementary text on the side:

This way it looks much cleaner, and although I use 90% less text, it says all that I wanted to say. Not bad.

P.S. While taking a screenshot for the previous point, I understood that I have a huge visual difference between right and left parts of my index page. On the left, I have a blog icon, blob with the welcome message and iPhone picture, while on the right, there are only visually light text. My first thought was: “Omg, I need to change the half of the page...”, but then I remembered about a project I’m planning to start and understood that the section for it would balance everything. “Good...”

So, stay tuned 😉

I really liked how Jonnie Hallman did that in his blog with minimalistic and slick looking categories. But I didn't want completely copy what he did. And after a few days of thinking how I can build something myself, I remembered about Justin Jackson blog with excellent articles for bootstrapers (highly recommend to read them), where he marked the hottest ones with the 🔥 emoji. And everything got set in my mind. I would choose a pack of different emojis and use them to make post categories. So every post would get an emoji explaining the general idea behind it. And since emojis can be understood in very different ways (well, It depends on context, I know), I have decided to show category description in tooltip on emoji hover. So the reader could always find what particular post would talk about. Decided, done.

To show all the blog categories existing right now, I have made a horizontal list with the emojis and also added some explanation texts, so the reader could understand what a is this for. I also planned to use these list with emojis to make the ability to sort the posts by category (Jonnie, if you read that - sorry, I really copied that from you). So you can click on the emoji from the list and blog posts gets filtered by this category.

However, looking at the final result the next day with a bunch of text lines, I understood that it looks filthy. Just look at it:

But I had no idea how to make all that neat 😐. I have played a bit with removing page title/description/categories list description, but it all still looked bad.

After some time I decided that it does the job, so I left it like this for now. Would definitely work on this in the future.

As every person who thinks about creating a blog, the first thing I thought is creating one on WordPress. I even have created one a few years ago, and hosted for free on wordpress.com. I have written one article there, and then the blog got lost.

Then, after my first blogging approach, I have learned quite a lot of programming. Mostly mobile programming (I use Flutter for day-to-day programming and from time to time write some native code), and a bit of web development too. Well, I had taken 2 courses (front-end, back-end) on web development on .NET in university. Still, the only thing that stayed with me is writing back-end code and some Razor while front-end (html, css, js) was nearly forgotten.

In my spare time, I launched a few games build on Flutter to start earning money by creating some “cool” products. Up to the day, I have made only a few bucks but got pretty more profound in development. Unfortunately, I couldn’t live for just a few bucks, so I started thinking about what to create next. Ideas were coming and passing, and I caught myself with the fact that many ideas rely mostly on the web rather than mobile usage. So I started thinking more and more about learning web development ...

As every mobile developer coming to the web world, I got lost. It feels like coming from the hills to dense forest. If you want to develop something for mobile, you would need to make just a few choices: going with native development (Android - Kotlin / Java, iOS - Swift / Object-C) or with some cross-platform frameworks (Flutter, React Native , and some other choices with different degree of wildness). But when you want to do something on the web ... the number of options are nearly countless. Really, there are thousands of languages ​​and tools for writing front-end, back-end or both in the same place ... Angular, React, Vue, Django, PHP, JavaScript, TypeScript, Laravel, Node, Rubys, .Net and thousand others. If you don’t want to drop a coin for few times and see where the chance gonna lead you, you could spend months trying to find some suiting tool for you, and you will still keep finding new and new ones with no end. I was feeling completely lost every time I was trying to understand how to approach the web. Well, there is AngularDart (the Angular with common to me Dart language), but Angular seemed overkill for the tasks I had in my mind. Doing projects on .Net seemed ... strange, it looked that no one on the web doing stuff on .Net. So this stayed in limbo ...

Now let’s get more closer to the topic:

During that time, I understood that I want to make myself a blog. Well, many different people write about their experience, and I liked to read their stories. And I thought that I may also have something to share.

Deciding where to build a blog

So I have dug into CMS solutions. WordPress was eliminated at the beginning since many bad things have been stated about it. You know, the security, hacks, other problems… Yes, there are a huge amount of plugins, tools, resources… But that didn’t buy me. During the research process, I have found many other CMS solution that looked better in my eyes.

In the end, I made a list of the tools to decide on. There were Craft CMS, Ghost, Statamic and Drupal. I really liked the look of Craft CMS, and Statamic also was very good. But after trying a sample of Craft CMS, I left a bit confused. It seemed kind of unintuitive in the way of building pages. And to run it, I needed hosting that cost at least 5$ a month, not a lot, but still money. Actually, I needed money to run any of them. Sad but what to do? Also, during the time of my research, Statamic charged more than 200$ for one site if you wanted to use it, which kindly removed it from the list. Recently Statamic got updated to version 3 with a free tier for personal usage, so it got much better in my eyes now. Additionally, Statamic blog could be generated into static pages now (in the next section you’ll see why this is an excellent addition). Ghost looked decent, it’s open-sourced as all 4 candidates with a good pack of plugins and resources available, while Drupal looked … a bit old … in design, feel … It shouldn’t be a huge problem, by the way, since it provides more plugins, themes, etc. compared to the previous three CMS’s. But, as every aspiring developer, I was looking for something fresh, new, cool …

Finding about static sites

This time, I have caught by Gatsby. Gatsby - I really liked the name for a tool. And the icon was appropriate. I read a bit about it, and also landed on Netlify page. I liked the look of their marketing sites, but it was still unclear how I can use that, so I just closed the tabs.

Later that time, I read something about JAMstack and, in some time, landed on their website. The message was right: fast sites and no need to run servers. So far sound good, and I dug deeper. Everything lives in Git, could be hosted literally for free... I have been bought.

Then I learned that Gatsby is used for making static JAMstack sites and many people host these sites on Netlify. You may think that everything was set. But not really. Something inside me just don’t want to go with React on which Gatsby is based. And after research about React vs Vue, the latest seemed like a better choice due to the easier learning curve. So I continued to search and found Gridsome, which looked like a complete Gatsby clone on Vue. So now he should be set, you may think. Not yet, sorry. I also have found Nuxt, which allows building not only static sites as Gridsome, but pretty standard, server run ones. So I thought that for long term learning Nuxt would be a better go. Now it is set. Partially. I also needed a CMS to operate with the content.

Choosing CMS

Choosing CMS for the static site was even a harder decision than selecting what to use to build a blog. After researching for the tools that are used with the static sites, I singled out several headless hosted CMSs and Git-based ones. For hosted ones, I was looking for those that don’t charge for basic usage, and choices were decent: Prismic, Storyblok, Contentful, ButterCMS. ButterCMS message was merely great: “Headless CMS you’ll melt over” - 15/10 points of greatness. There was also Strapi - it looked the best, but I needed to host it myself, so it didn’t fit.

In the same time, I was wondering if I should leave my content somewhere if I can have it all in my Git. With Netlify CMS, for example. And I really got stuck on this question. I was leaning toward Git-based CMS, but I still could not decide. Finally, I decided to drop a coin. I didn’t find any😂 and took a credit card instead. It worked great, and I got an answer - I need to go with Git-based CMS. I also made a small comparison between Forestry which is also Git-based CMS and Netlify CMS and decided to go with Netlify CMS at the end. The final decision was made mostly on the facts that Netlify CMS go well and fast with Netlify(surprise) that I wanted to use and are open-source. Additionally, I could preview the Netlify CMS admin interface, and I liked it. It was simple, clean, basically everything I needed.

Making it live

To make all this live, I followed setup instructions for Nuxt, Netlify and Netlify CMS, thankfully, they all are quite clear.

Only one thing that took a lot of time - is creating Nuxt project. On set up, you can decide between JavaScript or TypeScript for the primary language. I didn’t want to go with JavaScript, since using dynamically typed language after statically one is really the pain. But I thought that finding tutorials on JavaScript would be easier and went with it. You also may choose some additional modules, plugins which also took time to research what to add. But the biggest pain was selecting a linting package for js. To keep it short, I could not run even Hello World project before I have deleted all the linters.

Luckily, Netlify smoothed out my angry feelings later on since it is really no friction in use. Two clicks and your website is ready - great service. Connecting Netlify CMS also went without problems. Their docs lead through all the steps you may need.

And after some basic styling I, finally, got my website up and running.

While all people would go straight to WordPress when they think about creating a blog, I decided that I would go through the jungles and code my blog on JAMstack (mobile developer going to code his web blog...that's sounds creepy, at least for me). But, why not WordPress, you may ask? Well, first you need to pay for the hosting, but I didn't want to pay a penny since I have spent all my money to buy the domain name. Second, I wanted to learn some web development. You know, when you do fine with mobile development and trying to create some "SaaS business"(why not?) at the same time you catch yourself thinking that what if I would need to create a website ... and you have just ... blank screen.

So I decided to change that a bit.