Day One Classic to Plain Markdown (Obsidian) Migration Tool

https://github.com/azat-co/day-one-classic-migration

Day One Classic was a good journaling app but sadly the modern Day One app suffers from feature bloat-creep and requires subscription for synchronization. Your data should belong to you. Let’s see how to break free from Day One Classic into plain Markdown that can be used by any free or open source editor like Obsidian.

Obsidian has community plugin for importing Day One JSON files. The problem is that Day One Classic doesn’t have JSON export and only exports into single files in PDF, TXT, MD. So this Node.js script takes DO source files and converts them by year and date into plain markdown files. Perfect for Obsidian but will work with any other modern editors. The tool preserves DO meta data like location, weather, dates, host name and so on.

The problems it solves and how it fixes them

  1. Day One Classic v1 can only export single TXT, PDF, or Markdown files.
    – The script reads the raw XML/plist archive inside your Journal.dayone bundle and turns every entry into a separate Markdown file, so you get a real file-based journal instead of one huge document.
  2. Most converters ignore important metadata.
    – This tool keeps everything: creation and modification times, tags, GPS coordinates, weather data, even the computer’s host name. All of that is written into YAML front-matter that Obsidian (and other editors) can query.
  3. Exports usually leave you with messy filenames.
    – Each note is named YYYY/MM/DD-HHMM.md and placed into year- and month-level folders. That mirrors Day One’s timeline and keeps large libraries easy to browse.
  4. Converters often tie you to one note app.
    – Output is plain Markdown plus a photos folder. Drop it into Obsidian, Logseq, Ulysses, VS Code, or just store it under Git for long-term archiving.
  5. Other tools can be hard to set up.
    – If you have Node 18+ (common on dev machines) you can run it with a single command:
    git clone … && npm install && node migrate.js.
    No Python environments or Homebrew taps required.
  6. Privacy or cloud-lock concerns.
    – Conversion happens entirely offline on your Mac. Nothing leaves your computer.
  7. License worries.
    – The script is MIT-licensed, so you can use it commercially, fork it, or embed it elsewhere without legal friction.
  8. The codebase is short and readable—tweak the output template or add Obsidian wikilinks in minutes.
  9. Plain Markdown plus image files is about as future-proof as it gets.

https://github.com/azat-co/day-one-classic-migration

For anyone still using Day One Classic and looking for a fast, offline, open-source path to a modern Markdown vault—complete with photos and full metadata—this Node.js script is the simplest bridge available.

Top Five Traits of a Good Software Engineer and How to Develop Them

I’ve been in software engineering/development for over 20 years. I’ve noticed when I did a good job and when not. I’ve noticed how others have struggled to do a good job and what inhibited their potential. Here is my list of top five traits and abilities that distinguish a good software engineer.

  1. Focus
    • Deep Work: The ability to engage in deep work, which involves extended periods of uninterrupted concentration, is crucial. This allows for the tackling of complex problems and the development of innovative solutions.
    • Task Prioritization: Effective focus requires the ability to prioritize tasks and manage time effectively, ensuring that the most critical tasks receive the necessary attention.
    • Minimizing Distractions: Developing strategies to minimize distractions, whether they are from the environment, such as noise, or from digital sources, like social media, is essential to maintain high productivity.
  2. Stamina
    • Physical Endurance: The ability to sit and work for long hours without compromising health. This can be enhanced by maintaining good posture, taking regular breaks, and incorporating physical exercise into daily routines.
    • Adaptability to Environments: Being comfortable working in various environments, from noisy open office plans to cramped airplane seats, and still maintaining productivity.
    • Mental Resilience: The mental endurance to push through tough, monotonous tasks and stay motivated during long projects, especially when faced with tight deadlines or challenging problems.
  3. Logical Thinking
    • Analytical Skills: Breaking down complex problems into smaller, manageable components and analyzing each part systematically to find a solution.
    • Debugging Proficiency: Developing a methodical approach to debugging, including understanding error messages, using debugging tools, and writing tests to identify and fix issues.
    • Algorithmic Thinking: Applying logical thinking to design efficient algorithms and optimize existing code, ensuring that solutions are not only correct but also performant.
  4. Good Memory
    • Knowledge Retention: Retaining information about the codebase, including classes, libraries, and methods, to avoid redundant searches and improve coding efficiency.
    • Pattern Recognition: Recognizing patterns in problems and solutions, allowing for the application of previously successful strategies to new challenges.
    • Continual Learning: Keeping up-to-date with new technologies and remembering how they integrate with existing systems to maintain a modern and efficient workflow.
  5. Good Communication and Writing Skills
    • Clear Documentation: Writing clear and concise documentation for code, APIs, and systems that can be easily understood by other developers, both current and future.
    • Effective Communication: Clearly expressing ideas and solutions in written form, whether in emails, reports, or code comments, ensuring that all stakeholders have a clear understanding of the project’s status and requirements.
    • Collaboration: Writing detailed instructions and guides for colleagues, facilitating collaboration, and ensuring that team members can quickly understand and contribute to the project.

Practical Tips for Developing Top Traits for Software Engineer

  1. Focus
    • Practice techniques like Pomodoro for time management.
    • Create a distraction-free work environment by using noise-canceling headphones or software that blocks distracting websites (or even better turn off the internet).
    • Pick a quiet room without windows or any other distractions. Cafes and modern open offices are not for software engineering work.
  2. Stamina
    • Incorporate regular physical activity into your routine and healthy eating to build physical stamina.
    • Use ergonomic furniture to reduce physical strain during long work sessions.
    • Do regular eye exams to reduce fatigue due to poor vision and strain on the brain through eyes.
  3. Logical Thinking
    • Play chess or checkers, solve puzzles and engage in activities that require critical thinking to sharpen your logical skills.
    • Regularly practice coding problems on platforms like LeetCode or HackerRank.
    • Engage in debates trying to convince others of something (which you may or may not believe in), just for the sake of practicing argumentation and logic.
  4. Good Memory
    • Use tools like Anki for spaced repetition to help remember programming concepts and details.
    • Regularly review and refactor your code to reinforce memory.
    • Practice writing code without the internet, that is without the ability to search for answers and just by relying on reading source code and remembering interfaces.
  5. Good Communication and Writing Skills
    • Write daily, whether it’s blog posts, detailed comments in your code, or personal journals.
    • Read technical documentation and learn from well-written examples to improve your own writing skills.
    • Read a book or too on English grammar and copywriting.

By consciously working on these traits, a software engineer can enhance their effectiveness, productivity, and ability to contribute significantly to their team and projects.

Adding constraint on a foreign key with node-pg-migration

node-pg-migration is a useful library. You can add a constraint of a foreign key with a simple references property on the column. For example, you have table client_session with publishable_key column and you want to reference publishable_key column in workspace table where it is not a primary key (just a unique key). The following usage with object: schema, name, won’t work:

 pgm.createConstraint({
    schema: "seam",
    name: "client_session",
  }, "client_session_publishable_key_fkey", {
    foreignKeys: {
      columns: "publishable_key",
      references: {
        schema: "seam",
        name: "workspace",
      },
    },
  })

 If you write a migration for Postgress and Node.js using node-pg-migration (e.g., table 1) and want to create a foreign key reference / constraint (createConstraint or references on createTable) on a non-primary key of the other table (table 2), then references by an object containing schema and table name, do not work. This is probably a bug in node-pg-migration. It tries to match primary keys only, but our publishable_key is not a PK in workspace.

It looks like node-pg-migration is not smart enough to add the column/field name like it does for primary keys. You can use a string (seam.table2(col)) as the references value, not an object, or just use raw SQL to bypass node-pg-migration behavior, e.g.,

 pgm.sql(`
    ALTER TABLE seam.client_session
    ADD CONSTRAINT client_session_publishable_key_fkey
    FOREIGN KEY (publishable_key) REFERENCES seam.workspace(publishable_key);
  `)

Or in the node-pg-migration method:

 pgm.createConstraint({
    schema: "seam",
    name: "client_session",
  }, "client_session_publishable_key_fkey", {
    foreignKeys: {
      columns: "publishable_key",
      references: "seam.workspace(publishable_key)"
    },
  })
},

How to show all constraints on a Postgres table

I recently needed to update the check constraint on a Postgres table column. This check does format validation similar to regex. This check was part of the CREATE TABLE statement meaning it was created with the table.

However, ALTER COLUMN is not supporting updates of checks. So what we need to do is to drop the constraint and create a new one. dropConstraint requires the name of the constraint, but the name is not obvious. This is because check was create with createTable. To find the name, there’s a SQL query we can run:

SELECT con.*
       FROM pg_catalog.pg_constraint con
            INNER JOIN pg_catalog.pg_class rel
                       ON rel.oid = con.conrelid
            INNER JOIN pg_catalog.pg_namespace nsp
                       ON nsp.oid = connamespace
       WHERE nsp.nspname = '<schema name>'
             AND rel.relname = '<table name>';

📱💬Leveraging Messengers for MVP Validation and Sales in Your Tech/IT Startup

As a startup founder, you might think that building an app, whether it’s for the web or mobile, is the only way to validate your business idea. However, that’s not necessarily the case. In fact, using messenger apps like WhatsApp or Telegram can be a great way to test the waters and validate your concept with minimal resources.

In most cases, startup founders don’t need to build apps (web nor mobile) to validate their ideas. For a minimum viable product (MVP), it’s good enough to “fake it till you make it” with a manual service by a human over a messenger. This is because even non-MVPs use it.

I’ve ordered cakes, cigars, flowers, meat, taxi, nanny, cleaning and many other products and services over WhatsApp. I’ve paid in my banking apps, after I got the payment info via WhatsApp. I’ve scheduled personal trainers, car services and others via WhatsApp and then paid cash.

In fact, there are already many industry use cases where messenger apps are being used to provide products and services. If you think about it, Uber, Rappi and Instacart often rely on messages to confirm destination or replacements of grocery products. The core of their app is catalog and messaging which can be done in WhatsApp or Telegram. Catalog can be done for the MVP with a PDF or just images sent over the messenger.

Let’s say your MVP is not an e-commerce where clients pick a product form a catalog and make an order. It’s something more complicated. Then you do the complex thing manually by a human and get results via messenger.

In the end, don’t waste time and money on building web or mobile apps. Just validate and make sales with WhatsApp or Telegram first. 💡🚀

What’s new in React 17: new features and improvements

React.js version 17 was released in October 2020 and introduced several new features and improvements. In this blog post, we’ll explore the major updates in React.js version 17.

No More Event Pooling

One of the most significant changes in React.js version 17 is the removal of the event pooling optimization. Previously, React.js used a technique called “event pooling” to reduce the number of event objects created by the browser. However, this technique had some drawbacks, such as preventing the use of asynchronous event handlers and making the code more difficult to reason about.

With React.js version 17, the event pooling optimization has been removed, and every event object is now a unique instance. This change allows developers to use asynchronous event handlers and makes it easier to reason about the behavior of event handling in React.js.

Continue reading “What’s new in React 17: new features and improvements”

MMAT: My Teaching and Learning Approach

In our day and age, learning is more important than ever because things change so rapidly. I learned a taught a lot of things during my career which led me to discover that the best and the most effective learning method is to use MMAT: Motivation, Methodology, Action and Time.

Continue reading “MMAT: My Teaching and Learning Approach”

Why I’m Getting a Second Master’s Degree from HEC Paris

Two months ago, I applied and was accepted to a master’s program at a prestigious business school (ranked #2), HEC Paris. The degree is title Master of Science in Innovation and Entrepreneurship (MSIE). It has 10 normal courses, 10 practical project-based courses and one large team project. The master’s program lasts about one year and a half. Thus the program ends in 2020. However the graduation will be in 2021, because HEC has only one graduation ceremony which is held in its beautiful Paris campus.

Continue reading “Why I’m Getting a Second Master’s Degree from HEC Paris”

Acquisition of Node University by DevelopIntelligence

After 2.5 years of starting my online school for software engineers Node University and growing it to one of the best resources on Node.js, APIs and AWS, I’m happy to announce the acquisition of Node University by the tech training company DevelopIntelligence. 💰😎🍾 I’ve known and worked with DevelopIntelligence for many years. They deliver outstanding in-person tech training to Fortune 500 companies. The synergies and future of combining in-person with online training are massive. I’m sure the new team will take Node University to the next level! 🚀

Azat’s Management Philosophy

Have you ever wondered what your manager is doing all day? Are you guilty of secretly thinking he/she is playing Candy Crash and attending endless stream of useless meetings? If yes, then you are normal. Management is often invisible and hard to understand. We have tons of books and courses on management but too few good leaders. Sadly, many of us had a bad boss and too of us had a great boss. This post will share my approach to being a good leader.

My management philosophy revolves around three things but one of them is the most important because if we get it right, then all other parts will fall into place. One thing that I care about the most, and which is my main job, is people. I coach, mentor and help people to grow in their careers. I find their strengths and talents. Most people are not that great at self awareness and self observation because their insecurities, desires or emotions interfere with the clear perception of reality. Observing people from outside as a manager or peer gives much better results—a much cleaner and fuller picture.

Continue reading “Azat’s Management Philosophy”

Why GraphQL is Taking Over APIs

A few years ago, I managed a team at DocuSign that was tasked with re-writing the main DocuSign web app which was used by tens of millions of users. The APIs didn’t exist yet to support our new shiny front-end app because since the beginning the web app was a .NET monolith. The API team in Seattle was taking the monolith apart and exposing RESTful APIs slowly. This API team consisted of just two engineers and had a release cycle of one month. Our front-end team in San Francisco released every week. The API team release cycle was so long because a lot of (almost all) the functionality had to be tested manually. That’s understandable. It was a monolith without proper automated test coverage after all—when they modified one part, they never knew what can go wrong in other parts of the application.

Continue reading “Why GraphQL is Taking Over APIs”

Practical Node.js, 2nd Edition: Colored Print Book is Ready

The Practical Node.js, 2nd Edition print book is finally ready. It turned out the biggest thickest book I ever wrote (500+ pages). Practical Node, 2nd Ed. is even thicker than React Quickly.

The Practical Node.js, 2nd Edition print book is finally ready. It turned out the biggest thickest book I ever wrote (500+ pages). Practical Node, 2nd Ed. is even thicker than React Quickly.

Continue reading “Practical Node.js, 2nd Edition: Colored Print Book is Ready”

Triage vs. Planning

A discussion came up in at my work about distinction between a triage and planning meetings. My take on this is that triage reactive whereas planning is active.

Let me illustrate this with examples. Imagine a customer-facing app like a WordPress CMS. Users use the CMS, encounter bugs, and curse. They sometimes report the bugs. An engineering team or a product manager will triage the incoming bugs and issues to sort out what need an urgent fix and what can be deferred. Bugs tend to be urgent but not always important (at least not important for the majority of users).

On the other hand, there is an important task. The CMS has a roadmap to add a paid feature that should increase company revenue and make the next year profitable. The paid feature needs to be implemented. It’s the top priority. Its implementation must be planned actively, separately and before any bugs. If not planned, bugs can take up all the time.

Thus, my suggestion is to plan and plan the priority first. Then plan the triaged work on bugs and tech debt. Focus on important first, not urgent.

Breaking Into IT and Tech as a Beginner

I got an email from a person frustrated that he can’t get an entry-level job in IT/tech. He knows PHP, HTML, CSS and MySQL, but he is tired of all the companies rejecting him and requiring a “perfect” expert (as he put it). That’s true that there are not that many entry-level jobs in tech. It’s hard break into tech. Most companies only interview senior engineers with at least five (5) years of industry experience.

Continue reading “Breaking Into IT and Tech as a Beginner”

Tricky English Grammar for Programmers

As I was editing my new book Practical Node.js, 2nd Edition, I found a few recurring mistakes that my publisher’s editor was correcting. I wrote over dozen of books but I still don’t know some of English grammar. Do you know some of these tricky rules?

  • Front-end app vs. frontend
  • Which vs. that
  • While vs. whereas
  • May vs. might
  • Login vs log in

Front-end is an adjective while frontend is a noun. For example, “I build front-end systems”, but “I work on the frontend”.

Which needs comma and it is less important than that, which is used without a comma. The which clause can be removed but the that one cannot be removed without the loss of the meaning. For example, “I like Node.js, which is JavaScript on the server”, but “Create a file that starts the Koa server”.

While and whereas are similar when you contrast two things, but whereas is a bit more formal (and less used in spoken language). While can be used for timing but whereas cannot. For example, “window is a global variable in browsers while/whereas global is in Node”, but “When it’s noisy in cafes, I write code while listening to Spotify”.

May has more probability than might. For example, “I may go to Japan next quarter”, but “I might quit Node.js and move to Denmark to study Artificial Intelligence”.

Finally, login is a noun and log in is a verb. For example, “Implement login using OAuth 2.0”, but “You need to log in to AWS console as admin first and only then create a new user”.

5 Habits of Highly Successful Software Engineers

There are multiple ways how software engineers can achieve a successful career. Some can be early employees at Google while others can be a life-long employees of IBM. Some can build side projects while other can get equity. But there are only five common habits and traits:

  1. LEARN: Find balance between learning and doing. Have a solid knowledge of fundamentals either from college degrees or from educating yourself with books and online courses. Constantly apply your knowledge to practice.
  2. WORK: Find balance between productivity and rest. Consistency in productivity is better than burnout.
  3. CONTRIBUTE: Learn the business side of things. Produce highly valuable products which are useful for customers and beneficial for the business.
  4. INNOVATE: Invest in a forward-thinking technology that a reasonable person would expect to become more in demand and desirable over tie.
  5. THINK LONG-TERM: Treat others with respect, honestly and fairly. Think and act long-term. Contribute to open source or teach because it helps you and others.

Programmer vs. Software Engineer vs. Software Developer vs. Coder

Hello everyone! In this post, I want to contrast the terms with which other people and we ourselves call us. There are a lot of confusion around the names for our trade. People use terms such as software engineer, software developer. Some people even use programmer or coder, etc., etc. And some event go as far as ninja, guru, or rock star. So let’s take a look at the differences. Of course, it’s all just my opinion but I’ve been in this industry for 15 years. I know a bit or two. So let’s go ahead.

Continue reading “Programmer vs. Software Engineer vs. Software Developer vs. Coder”

5 Reasons Programming is Awesome

Let’s start from the smallest to the biggest five reasons why programming and software development is awesome.

The reason number 5 (smallest) is programming can pay really well. The average income in the USA is somewhere along $50K per year per household. Programmers typically starts their careers with $80K/year salaries. In major metro areas the salaries are way higher than that. They can easily be in the $120–150K/year range.

The reason number 4 is that you are never bored. There’s always something new. Sometimes new technologies come out before you even release your product. Thus, you are never out of things to learn and update. A lot of people are bored out of their minds at their jobs. Most of them perform the same mundane tasks for 5, 10, 15 years… Not you. Lucky you! Programmers can always grow, learn and master the skills by learning and seeking more challenging problems and solving them.

The reason number 3 is that it’s a real career. Some jobs are not careers. Avoid them. For example, a taxi or an Uber/Lyft driver will always be a driver. A Denny’s waitress will always be a waitress even after 40 years at her job. It’s a dead end. Avoid it. A lot of programmers start as junior developers/engineers, then they progress to associate developers. This could happen in as short as two (2) years. After that, some of them are promoted to senior developers in as short as 3–4 years. That’s not all. The path continues to principal, staff engineer, architect, manager, director, vice president of engineering and to CTO. A lot of tech companies have engineers as their senior leaders, e.g., Microsoft, Google, etc.

Continue reading “5 Reasons Programming is Awesome”

My New Book Concept and Top Qualities of a Good Software Engineers

Packt Publishing reached out to me and offered to do a book.

They pretty much want me to do any book and pre-agreed already. They gave me carte blanche on the topic.

(More or less, I doubt I can convince them to publish a vampire thriller set in a Silicon Valley startup.)

Funny thing is that I know the editor. He worked at Apress Media when I published my first book Practical Node.js with them.

I submitted to them my idea about a software engineering career book for junior developers. They liked it. It can become a book!

While thinking about the career in software engineering, I thought about top skills.

As in any profession, software engineers requires a combination of certain skills and techniques.
I’ve done software engineering for over 15 years.
I taught total beginners (in Hack Reactor) and professionals (in Fortune 500 companies).

The most important skill in a good software engineer is not smarts. No. It’s not how good he can write code.
It’s not soft skills either

Continue reading “My New Book Concept and Top Qualities of a Good Software Engineers”