DEV Community: Vitaly Krenel

Online ChatGPT-powered startups hackaton // coding not required

Vitaly Krenel — Thu, 09 Feb 2023 10:43:58 +0000

Hey folks! I'm looking for support to organize a ChatGPT-powered startups hackathon this or next weekend.

💡 Hackathon idea so far

what

build a proof of concept for a problem with ChatGPT. 24 hours for you to to come up with a proof of concept of a solution with #ChatGPT for an existing product or a new one. Proof of concept: a Notion paper, a zero-code app, or a bot — anything doable quickly.

who

anyone from startups and product companies. Existing product managers, product-minded engineers, etc. Basically anyone who want to apply ChatGPT to product companies.
team or solo. You can join together as a whole startup team or just by you-self to pit your wits and innovate
coding skills not required. Just desire to look for ideas or problems and to figure out how to apply ChatGPT to it

why

built a proof of concept blazingly fast. You’ll come up with an AI-powered proof of concept to boost your product or may become a new startup or solution to sell to other companies.
prizes. there will be nominations and winner will have prizes.
intros with accelerators/VC. I’m looking for ways to make intros with EU funds / accelerators. Already have 1 fund looking for expansion in EU region and considering exinsting startups for portfolio.
fun & engaging. Look for a solution together quickly — it's not a day to day job.
AI literacy leveled up. This new type of literacy often referred to as the "3rd literacy," is essential for anyone who wants to take advantage of the many benefits that AI has to offer.

where

online, Lisbon / London timezone. Time and date to be confirmed if I actually manage to start this 😄

Do you teach/mentor other people coding? Why?

Vitaly Krenel — Mon, 14 Dec 2020 09:59:03 +0000

If yes, then why do you do that?

Hey folks! Being a quite diverse engineer, I decided to start intentionally mentor other aspiring devs 2.5 years ago.

Recently, I asked myself a question: "Why do I do that?" and found myself having a lot of different answers.

I decided to think it through to find out what is my motivation in this endeavor? Why do I mentor other developers?

I took a few hours to think it over and found them quite helpful.

I settled on a few facts

I'm not doing it for profit.

I'm not making a lot of money on this one or even enough money to sustain myself.

I do not argue here, that mentoring can not be a profitable business or it shouldn't be. I don't have an opinion on this one as it's just not how I use mentoring.

At the same time, I do think that it is okay to settle with your mentee on some payment. Especially, if you want to help them to discipline themselves. The amount should be reasonable for your mentee, rather than for you.

I believe, people tend to take things more seriously when money gets involved.

Mentoring challenges me to explain things clearly.

Less experienced engineers ask sometimes quite straightforward questions. Which occasionally may touch some things, you don't know well or believe you know, but you don't know well enough.

This is helpful to continue staying humble, even as you get more experience. It also teaches saying "I don't know" and forces you to brush up on the subjects you are not confident with.

Connects me with new engineers I may work with in the future.

Someone said to me once: "All the rock stars have already been taken. We should grow our own ones inside".

It was through the process of looking for new strong engineers for a project.

The idea is that if you are skillful enough and mentor someone things you know, you are likely to teach them good practices, patterns, and tools you are using.

If your mentees are working in some companies, they'll continue to evolve the practice you are using and validate them. Through just a couple of years, they'll build new knowledge on the fundament you've given.

This will make these engineers you've mentored quite suitable to work with you (as they have similar preferences) and at the same time they will also see problems, you may not be aware of (as they validated your knowledge through other workplaces and tech teams).

Hopefully, this will make the project you'll be working on together a bit better.

Those were my thoughts. Can wait to hear from you - maybe I'll realize that I'm not the only one who thinks this way.

So what are your reasons to mentor other developers?

Learning resources 📚 for understanding Javascript async nature 🔮

Vitaly Krenel — Wed, 14 Oct 2020 19:19:50 +0000

Over my mentoring practice, I often see the stage of learning, when an aspiring developer starts tackling the asynchronous nature of the Javascript.

And over the last year, I've built a small, though an unbelievably helpful collection of resources for learning the asynchrony concepts and the concurrency model in JS well enough.

It should be enough to let you work with asynchronous javascript in your day job (and demonstrate the knowledge in tech interviews before that).

Specifically, this collection can be helpful in learning:

Promises, callbacks
Event Loop model and queues
async/await operators

These are not obvious as they might seem and sometimes may be difficult to crack.

Learning resources

🔮 "Async & Performance" book from You Don't Know JS series by Kyle Simpson (aka. getify). Specifically, take a look at chapters 1,2, and 3.

❗🏋 The book is relatively harder than other recommended resources, but it covers the whole theory behind asynchronous concepts in Javascript.

If you are a junior javascript developer going through interviews, you should explore it, despite the difficulties - with that, you'll ace any async related questions on the interview and will impress the interviewing team.
🤞 "Javascript Promises: an introduction" by Jake Archibald - great explanation of Promises, friendly and not shallow at the same time.

There are many useful examples (but they take time to understand fully, sometimes) - and I recommend you to play around with them in a Codesandox so you really feel comfortable with them.

By the way, the article author - Jake - posts quite friendly and interesting articles in general, so you might want to check out those later as well.
➰ Talk "What the heck is the event loop anyway?" by Philip Roberts - one of the best talks about Event Loop model which is what is the foundation of the concurrency in JS. It's a must-watch. The talk is both fun and enlightening.
➿ Talk "In The Loop - JSConf.Asia" by Jake Archibald (the author of promises introduction at the top) - it's related to the Philip Roberts talk, and is a great follow-up.

On top of that, it covers aspects of the Event loop that are important to the actual understanding of Promises (which Philip Roberts didn't cover).
🦄 "JavaScript Visualized: Promises & Async/Await" by Lydia Hallie - this article should help you solidify the learnings so far.

The visualizations there are especially helpful to keep your knowledge in the long-term. Those visual images not just ease the learning but also reinforce your memories in the brain, so you are less likely to forget.

And it also covers async / await concept - synchronous like syntax to write Promises-based code in a more straightforward way. Async / await are essential tools for writing readable and maintainable logic based on Promises in modern projects.

In what order to learn using this collection?

In the beginning, try to use the default order - as they go in the list above.

But if you find yourself struggling with the 1st item - as I said, it's relatively harder than other recommendations - use the alternative order:

Start with the article series by Lydia Hallie: 5
Go through the 2nd to 4th items: 2, 3, 4
After that come back to the 1st to deepen your knowledge and help yourself to ace the tech interviews 😉: 1

Why I don't use the alternative order as the default in my mentoring practice? It's easy: to challenge the mentee.

The book "Async & Performance" really makes you go through the complex concepts that stay in the basement of JS asynchrony. If you can handle those - there will be fewer subjects in JS that will be able to make you break a sweat, that's for sure 🙂

And so that's all, my friend. Hope these resources will help you on your Javascript learning path!

What's next?

If you like these resources, you might also be interested in BandaWorks twitter community.

Every day we post valuable content for junior developers there, among those:

Daily advice to help you become a stronger developer
Learning resources for web development
Overview and our own thoughts on the development articles by other authors

// Detect dark theme var iframe = document.getElementById('tweet-1313829364103077890-325'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1313829364103077890&theme=dark" }

Join us if you are the same as we - focused on continuous improvement! 😉

Job hunting 101 for junior developers

Vitaly Krenel — Tue, 13 Oct 2020 21:56:04 +0000

Photo by Gerald Schömbs on Unsplash. Modified by Vitaly Krenel

It's okay, Shark, I've got you covered.

The job looking process can be split into 2 stages:

Preparation
Job looking

1. Preparation stage 👨‍🍳

This is finishing part of your learning path on the way to junior position. Keep in mind, that the actual learning should never end, just you'll be investing some spare time to learning while having an official developer position.

Usually, together with my mentees, we take around 2-4 weeks (rough estimation, it may vary, depending on your skills) and after that proceed to the job looking (and improving any weak side on demand, after getting feedback from a company).

During the preparation stage 🍳

Build your portfolio.

I usually suggest creating a website that features your strongest projects, but these days there's also a GitHub Profile option.
- If you choose to build your own portfolio website: https://dev.to/emmabostian/how-to-build-a-great-technical-portfolio-53bb
- For Github Profile, take a look: https://dev.to/m0nica/how-to-create-a-github-profile-readme-1paj
Start exploring how the interview process looks like.

Find out questions and assignments that you can be asked to answer/solve during interviews.
- I strongly recommend exploring the interview handbook during this step - it contains both typical questions (HTML, CSS, JS) and theory you need to know to answer them: https://github.com/yangshun/front-end-interview-handbook
- For more javascript specific questions, take a look at this collection https://github.com/ganqqwerty/123-Essential-JavaScript-Interview-Questions
- Don't forget to practice coding challenges. There's a bunch of resources Chris Choyer gathered here: https://css-tricks.com/front-end-challenges/
I suggest you spend invest some time practicing CSS challenges, as an addition to JS-specific problems.

This way, you will less likely to struggle if interviewers ask you to stretch elements over the screen or position one small block inside a scrollable container.
Set up your profiles on job searching platforms and LinkedIn. It increases your visibility for recruiters which may invite you to interviews if you match one of their posting descriptions.

I do not recommend counting on this strongly, but it may provide few opportunities to get an interview, so it's definitely worth considering the time required to set up accounts there (spoiler: it's not that long 😁).

2. Job looking stage 🕵️‍♀️

It takes time

Be ready to persist for 1-2 months if you intend to get an offer tailored for you — this stage is truly about patience and persistence.

If you hurry too much, you may end up getting an offer in a team you don't want to work with or deal with the projects you aren't thrilled about.

Carefully assess the terms

On top of that, employers are often offering you less than you are really worth, as they imply you don't have much experience as thus they will be taking on more risks than with a regular developer.

While this is true, you still need to assess carefully whether the company offers you a reasonable payroll: it's an investment for them.

It for sure has risks, but the return on investment may be much quite impressive as well, especially if you are diligent, hardworking, and focused on continuous learning (which, I believe, you are! 🙂).

Wait for a few offers to choose from

So, instead of agreeing immediately to the first offer you get, I usually recommend reaching the point when you have a few ones (at least 2-3).

With that, you will not feel like the job terms were forced on you: you'll be the one choosing and you could also negotiate a little bit as you have a few offers and you will be able to have a more reasonable career start (both financially and professionally).

But please, don't leverage the company just for the sake of money - if you feel the terms are reasonable enough, don't squeeze from the hiring team a few extra bucks.

It's wiser to start in good faith and discuss the raise after getting on board when you'll prove your hard work and determination. 😉

During the job looking stage 👀

Everyday screen for job offers on the market and send at least 3 replies (the more the better, but send at least 3).

Why? Because many of your job applications may be easily ignored or declined with a typical message.

Take a look at the numbers from one of the bootcamp graduates' article: https://www.freecodecamp.org/news/5-key-learnings-from-the-post-bootcamp-job-search-9a07468d2331/

It is really an important thought to keep in mind so you don't discourage yourself.
Use Google Spreadsheet to keep track of all the job postings you applied to.

Store all relevant information there: your thoughts about the company, current status, and so on. It is easy to lose track of them when you reach just 10-15, not speaking of 200 😅
- Search for companies that are hiring using the job searching platforms, like indeed.com, Glassdoor, and definitely, LinkedIn - a lot of HRs and companies post job offers there.
Also, take a look at your country's local platforms if there any. For example, in Russia, we heavily rely on hh.ru and I believe in many non-English countries there are also local job search platforms that have a huge market share.
Target a company, not a vacancy.

Look for the information on the company you are applying for and craft a tailored response showing you are actually interested in the company. A few examples of things you might be interested in:
- What products company has built?
- What product do you like the most?
- Did the company participate in meetups or confs? Are there any interesting talks for you?
Imagine a situation, when you were researching all that and found that one of your personal projects in the portfolio is similar to one of the company's projects - you should share that when applying. That's exactly how you should use this information.

Show that you have the relevant experience, can quickly get into the work, and bring fresh thoughts to the product(s) there.
Find real people behind the company.

Instead of (or on top of) straightforwardly applying through job postings on those platforms, find real people that work in the company. Devs, HRs, even CEO - doesn't matter.

Many companies reward their employees when they bring new people on board, so if you reach out to someone real from the company, you have a higher chance to get an invite to an interview 😉

It's also that the job posting is managed by an external head hunter that goes over dozens of job applications. If you go to a person from the company, you'll have more chances to grab their attention as they do not deal with that many candidates on a daily basis.
Continue practicing.

Specifically, make more projects that showcase your skills.

It's much easier to grab a team's attention and to start wanting you onboard when you actually have a relatively complex project that is relying on a modern stack - even better if the tech stack is the same as the one used in that exact team.

For example, a React project that relies on

Redux Toolkit/MobX for store management,
React-router for routing,
Styled Components as CSS-in-JS solution,
Integrated with Firebase Cloud Firestore storing the data
Deployed on Netlify or Heroku

is a good showcase that proves that you can use production-ready tools for building something relatively complex.

It proves that you have real experience with frontend tools and can solve technical problems using them.

Moreover, in such a project the team looking for a teammate will be to assess your architecture skills, design patterns, find what coding principles you follow (and what you yet ignore), how you approach testing, and many other relevant aspects.

Basic applications won't suffice. They don't let you shine, they merely prove you have programming skills and development expertise - but that's not enough.

You need to make them feel you have reliable hard skills - you are not an expert yet, but do not need your colleagues full-time teaching you.

By the way, if you don't have any strong projects yet, take a look at Housework Undoer - it's a complex project that is inspired by our development experience.

It's story-based, so you'll be not just practicing how to code, but also practicing how to think about the product and its users in the first place.

So, what the interview is really all about?

That's an important question. If you think wrongly about interviews, you won't use a proper strategy.

Always remember: the interview is not about finding the almighty-problem-solver — it is about finding a reasonable teammate.

Teams are looking for a person that can reason about the problems clearly, investigate them, and can either figure out how to solve those or openly discuss the issues with the team.

Because of that, you need to show how you think, approach and react to problems.

So show that: during challenges, talk and explain what are you thinking about, why it is relevant, how you could try dealing with the suggested problem, what caveats do you see, which person you would consult on the question, and so on.

And that's it with job hunting 101. Hope this guide will help with the challenge of finding a suitable developer position.

Ganbatte, my friend, and you'll get a great job offer!

What's next?

If you like our articles, subscribe to our @BandaWorks community on Twitter so you don't miss the next ones 😉

On top of our article announcements, we post valuable content there every day:

Daily advice to help you become a stronger developer
Learning resources for web development
Overview and our own thoughts on the development articles by other authors

Banda Works

@bandaworks

#BandaDaily #1:

When #coding something, always approach the problem iteratively.

That means that as #developer you go through roughly 5 stages:

1. Make a straightforward solution
2. Cover edge cases
3. Improve the performance
4. Improve the design
5. Reduce complexity

🧵👇

13:11 PM - 07 Oct 2020

2 4

Housework Undoer — a meaningful challenge for aspiring junior developers

Vitaly Krenel — Sat, 10 Oct 2020 18:48:35 +0000

Do you remember, the time one of your friends asked you to build a website? What were your feelings?

Chances are you were excited, as you knew that you would be creating something, not for the sake of practice, but to bring value to someone else. To help someone.

Your work at that time had a context. You knew why you are doing it, you knew the reasoning behind the project, the problem.

Have you ever noticed, that is the exact missing piece with most of the project ideas out there on the internet?

They often are sophisticated, technology-savvy, and full of design delights. But at the same time, they lack context for the project.

They lack a concrete user problem — which is the exact reason why some projects may be built in the real world!

You may argue, that you are doing that project to practice engineering - why do you need to know all that stuff in such a case?

You are right. But now I'm not surprised why many companies devalue personal projects in juniors' portfolios and focus on looking for those that have actual work experience instead.

Because while you were working on those projects you were just practicing, not concerned with anything in mind, but the code.

At BandaWorks we like meaningful work. We value helping our community. And we are passionate about professional growth.

These three were the reason why decided to create our own project.

It's called Housework Undoer.

So, what is Housework Undoer?

Well, it's a project (your captain 😉). More specifically, it's a self-paced challenge split into multiple tasks through which you'll have to build a frontend application using your framework (React, Vue, Angular or Svelte).

Tasks define what you need to build, why, but not how.

Each one has a structure quite similar to the one used by development teams. They all include:

User story
Design mockup
Jack's comments
Acceptance criteria
Yoda's tips

Some of these might be new concepts to you, but as those are used by development teams, we decided to adopt them, even though you may not be comfortable with them in the beginning.

To flatten the learning curve, we prepared a quick introduction that should help you get a basic understanding of these concepts:

Housework Undoer is made in a way to let you'll get a similar experience while working on the project that we've been getting through our development careers.

You'll work in the development workflow that is strongly inspired by the development process in tech teams.

And as there's a context, it will truly make your work more meaningful, fun and entertaining while still teaching you how to think about your users first.

Technical stack

To complete the project you would need to use your UI framework of choice.

Of course, there's nothing stopping you from implementing using plain JS, but in the real world, it would be unsustainable.

So we recommend a few stacks, but you may complete the project in your framework if didn't include it:

React
Vue
Angular
Svelte

But to complete the project, you most likely will need to pick a few more packages on your own: routing, state management, testing, CSS-in-JS solution (or alternatively use a preprocessor), etc.

These will be left in your hands as you are the code owner of the project — you make the decisions there which later will affect how you build the project.

What if I want my own backend?

The project assumes usage of Firebase as a backend. But there's nothing that stops you from making your own backend, let's say using Laravel (PHP) or Ruby on Rails (Ruby).

There will be a few tasks where you'll need to integrate your project with:

Authentication to provide a sign-in for your users
Cloud Firestore - persistency, i.e. storing data in the database.

Only keep in mind, that at the time of writing "Yoda's tips" are providing only recommendations and insights on how to improve for frontend (but we may add backend later if there's some interest 🤓).

Skills requirements

There are 2 basic requirements:

Be confident in your skills with plain technologies like HTML, CSS, and JS. You need to use Git in your daily work.
Be familiar with one of the UI frameworks (Vue, React, Svelte, etc.) or be ready to put the hard work and learn it on the way.

If you don't match these, we recommend you wait and not work on the project right now: the difficulty may result in frustration which will kill the learning process.

Instead, continue learning and practice over a few small projects and after those get back to the Housework Undoer.

This way, you'll get more valuable experience from the project and will have only the necessary amount of frustration 😉

Frequently asked questions

How to start?

There're 2 options to start:

A. If you are not ready to set up a project locally and just want to give it a try, use one of our Codesandbox templates
B. If you already have decided, fork our starting repository on Github and follow our instruction for your framework

To pick either one, go to the Getting Started page straight away.

What if I get stuck or need help during the project?

It's easy: tweet your question with #BandaHelps and your Banda will be right there to help.

What to do when I'm done with the project

First of all, post the link to your repository with @BandaWorks mention on Twitter - we will definitely take a look and may even bring you a few thoughts on how to improve your code!
And don't forget to add the project to your portfolio - it will be a great addition showcasing your development skills to potential employers 😉

Are there any code review or mentoring on the project?

Right now, we do not provide mentoring on the project, but we offer the code review of your project when you complete it.

Where to send my feedback?

If you have any thoughts for us to improve, please send them to us.

The easiest way would be to use our feedback form.

But you could use other ways instead:

Post your thoughts right on Twitter with @BandaWorks mention - this way more people will be able to see your thoughts and this will help us improve even more. Even if the feedback is negative. We strongly respect transparency.
You can also reach us using our email: team@banda.works

What's next?

Subscribe to our twitter community @BandaWorks and stay notified on Housework Undoer updates and future project announcements!

We also post valuable content there:

Daily advice to help you become a stronger developer
Recommendations and thoughts on development articles by other authors
Our own articles announcements

// Detect dark theme var iframe = document.getElementById('tweet-1313829364103077890-465'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1313829364103077890&theme=dark" }

Thank you for your time and have a productive day! 😎

Principles for a junior developer to succeed in your first development team

Vitaly Krenel — Wed, 23 Sep 2020 11:19:25 +0000

While sitting in the deep nights behind the screen, practicing your craft, building projects, and learning new libraries, you were putting your best into mastering technical skills.

For sure, those skills are the primary pillar of the developer. The pillar that makes you a great engineer.

It didn't make you a great team player though.

To be a great team player means a lot of things. But probably the first one is to be reliable.

Unfortunately, I've seen many engineers misunderstanding the idea of being "reliable" as being able to solve any technical problem alone.

And that is exactly the opposite.

Let me share two principles, that I've been advising junior developers to stick with during my mentoring practice.

You may find many other principles, but these are a good starting point to make you a little bit better team player.

Which is what will help you to succeed in your first (and all next) developer job.

Principle #1: don't listen to your ego — talk to your team

You and your team trying to find solution together

Let's say, you got through the onboarding process in your first tech company, started your first task. You created a PR and got approved by your colleagues.

Enjoyed your first lunch with the team. Maybe got in love with a cool QA girl (or a boy) along the line. 😉

In the next few weeks, you were successfully closing tickets, finishing tasks with confidence. Had a few One-on-Ones with your manager or team lead.

Team lead
— The team likes you. We believe you are really competent - you solved all the problems without much intervention from your mentor. On top of that, you have a great personality, I believe you are a great match for the team.

You
— I'm glad to hear that! Thanks!

Finally, feeling proud, you start taking on more challenging tasks. And here you stumbled upon a hidden issue.

During the ticket, you discovered a problem you can't figure out how to solve. You going through it that day. The next day at the morning meeting, you say that "I encountered an issue, but I should be able to solve it today and continue with the rest of the task". Well, how could you not?

You tried again but couldn't crack it.

Maybe you found a probable solution, maybe you didn't. But the second day is getting to the end and there's still no clear progress on the task.

Let's stop here for now, as tomorrow you can just as easily say "I'm almost finished" again.

The problem in the exaggerated example above lies in your ego. Don't get offended, we all have that.

Well, it is your first developer job after all. You've finally got appreciated for the efforts you've put so far! For sure, you want to meet the expectations of your teammates.

At the same time, you likely want to have a successful career with rapid professional growth that shatters the assumptions about career advancement.

There's nothing wrong with those thoughts. But let them overrule you and you end up losing the ability to think critically in that situation. And we've seen what happens if you lose that ability: you won't ask for advice and instead, you will deal with the problem on your own.

But the thing is, if you care about not losing the credibility and actually proving that you are exactly who the team believes you are, you need to do exactly the opposite — you need to solve the problem together with your team.

Speaking from a business perspective, when you do not have a huge piece of responsibility for a product, if you take 3 days to build a feature instead of 1, you will not cause any harm — or at least any unsustainable harm that may make people think you are not right for the job.

Instead, you will show that in front of a challenge, you don't speak - you wait, hide, and play solo. Not a kind of team player anyone wants.

Notice, that we do not talk where is the team lead or your senior colleagues and why they do not intervene. We talk about your responsibility here as a team member.

You have to be reliable.

Being reliable means that you address any problem head-on, transparently discussing an issue and sharing your thoughts, especially if you are not sure how to solve the issue.

The takeaway: try as hard as you can to ignore the ego and always go and talk to your team. Tell about a problem, ask advice or start a discussion — anything to make it clear that you encountered some issue and not sure how to deal with it efficiently.

Don't get yourself to be blindsided by the feeling that asking for help will belittle your professionalism in the eyes of others. It won't.

Principle #2: Be braver — say (nonsense) aloud

Share your idea, even if it seems to look like this weird thing

The second principle is closely related to the first one.

Being part of the team also means taking a part in team meetings. Those may be brainstorm sessions, tech discussion, product meetings — as they say, meetings for everyone on the house!

Those meetings may be barely 3 people in one place or a room full of different specialists. No matter where you are, you might get afraid of sharing something as you don't want to end up saying a silly thing instead of the next brilliant idea.

Unfortunately for you, I'm about to say something you might not like: when you have an idea, a thought, or a feeling — even if it seems bold or unusual — say it aloud.

Yes, you may find yourself saying something obvious, inaccurate or even ignorant. If that's the case, people will say what's the issue with your suggestion and will move to the next thought.

They may do it roughly or more professionally, explaining what's the issue with the suggestion, but they will.

No matter how they do it, you end up learning about your product or technology a little bit more. And what's even more important, the chances of you bringing a meaningful and valuable opinion to this and future discussions have increased. That's super great!

Moreover, your thoughts do not have to miss the target all the time — and they actually will not.

First of all, you have fresh, bold, and full of raw potential mind of a junior engineer — this something companies are stacking on. This mind enables you to see the problem, without being restricted by knowledge of subtle nuances and tangled technical details of the product or technology.

You are looking at the "naked" problem, so to speak. It doesn't only mean that you are unaware of edge cases — it also means you are not limited by them.

And finally, you are closer to the user of the product so far than any more experienced engineer: they have been working in the tech field for quite a while and are super biased. Yes, you're biased too. But immensely less than anybody else. 😉

So my takeaway here: Don't hold on yourself back - speak up your mind, even if you think your idea might be nonsense. The more you do that, the more valuable ideas you bring to your team and your company.

Final thoughts

To shine in the workplace, especially in your first tech team, don't just bury your head in the code.

1. Look out for your team, talk with your colleagues and, when in trouble, ask for help — it does not make you unworthy of your job, it makes you a more mature and reliable engineer which knows how to control his or her ego (which we all have after all, but not all know how to control).

2. When participating in discussions and meetings (product and technical ones) be brave enough to share your thoughts, no matter how silly they seem. Firstly, you may find yourself sharing an idea which another team member may iterate on and improve it. And secondly, with each thought you share, you are making yourself better through feedback, by learning the product and tools behind it.

What's next?

There's one more primary principle that I usually explain and advise to stick with — take on responsibility proactively. But I'm intending to share it in a separate article.

In the meanwhile, I invite you to share your own principles, rules, or advice that a junior developer should keep in mind to become a great engineer and a reliable team member.

I also want to share a project that I and my partner have been working on for a while.

We came up with a challenging project to help junior frontend developers that need to showcase their skills and want to build a portfolio to ease the problem of getting a job in the industry.

You can check out it at https://banda.works/housework-undoer.

Houseworkd Undoer is a project organized into separate tasks through which you will build a frontend app to help our (imaginary) friend Jack.

We prepared a nice-looking design and a background story so we hope it should be enjoyable and interesting for you to build, while still providing enough challenges to display your skills to possible employers.

Housework Undoer's app screens.

See this in full size for more details 😉

To finish the project, you need some skills in one of the major frameworks/libraries (React, Vue, Svelte, Angular, etc.), though the project can be completed without any of those, just with plain JS (but keep in mind, employers usually expecting you to have knowledge and experience in one of those mainstream technologies).

In the upcoming future, we want to create a few more projects, including backend and mobile related ones. But we could really use your help as well: if you try on the project, send us feedback, your thoughts, and questions. The project is completely free and we will really appreciate you spending a little bit of time to share with us your thoughts over team@banda.works.

See you next time! 😉

A few more techniques to help you become a self-taught developer

Vitaly Krenel — Wed, 15 Jul 2020 13:16:16 +0000

Cover photo by Annie Spratt on Unsplash

Intro

Self-learning is the skill that changes people's futures. Sounds shocking, I know.

But jokes aside, being able to consistently and rigorously learn a subject without strict supervision, in my opinion, one of the most helpful skills you can acquire.

I always admired people who have been able to learn a language themselves, pick up the woodcraft, or learn how to play the piano. It seemed natural for them to stick with their activity for 8 hours straight without taking a break to eat something.

Unfortunately, I was slightly different. From a young age, I was quite good at "switching activities" or, let's face it, at quitting. I tried swimming, painting, volleyball, athletics, dancing, electrical engineering, piano (and some other classes and courses that dropped after a few trials).

Whatever course I'd take, I would usually quit it within 2 to 3 months. If I ask my parents, they most likely will admit that they were having bets on what date I would quit a new course.

Imagine now how my self-learning looked like.

Still, I was curious, young, and hungry. I easily could get engaged in new activities. And through exploring new things, I get to know how I can compensate my innate unwillingness to stick with the skill long enough that stoping makes no longer sense - I have already acquired it.

These days I'm involved in mentoring upcoming junior developers to help them steadily build skills that they feel confident with, no matter what challenges are in front of them.

In my practice, I noticed that some learners are struggling with the same problem I did when I was young: how to stay consistent, determined, and focused on learning without dropping again and again.

Today, I'd like to share a few techniques I advise you to adopt to increase your chances of learning the web development successfully and becoming solid self-taught developers, doesn't matter whether it is a frontend, backend, or any other part of the development world.

The inspiration for the article became a recent post on a similar subject from Desiré. Make sure to check that one out, there are more valuable recommendations you could try as well.

My learning method💡: what worked for me. ✍📖

Desiré 👩‍🎓👩‍🏫 ・ Jul 13 ・ 6 min read

#codenewbie #career #beginners #learning

1. Set up minimal daily learning time. 30 minutes per day is optimal. 📅

Quote by Shinichi Suzuki

One of the most essential rules that I recommend is to practice every day. And I mean it when I say every day.

The first few months of your learning, especially when you do not have any tech-related background, are fundamental as you are laying down the basis on which every follow-up piece of knowledge will be stacked.

This rule has a real benefit: it speeds you up in the long run as you rarely need to revisit the old subjects. You may still need to do it occasionally (some things are slipping from the memory, it is natural), but you less likely will need to spend several hours trying to grasp again the details you lost. Chances are high that a quick skimming through your notes or subject's summary will suffice.

In the beginning, people sometimes freak out hearing this rule. It may be related to the fact we got used to having 2 weekends where normally we can ignore the work. Initially, It may just seem "wrong".

But this rule is simply an adoption of distributed practice learning strategy that has numerous study based evidence that it is more effective than the massed practice (when you basically learn something in one session for a longer period of time).

It also does not force you to practice 4 hours per day every single day. Sticking to such a schedule may be extremely difficult, after all, many of us have work, family, or some responsibilities we have to focus on regularly.

This rule merely requires you to set up a minimal amount of time you will invest every day, including weekends, holidays. And, yes, on grandma's birthday as well.

Half an hour (30 minutes) in my practice proved to be the optimal number, but it may be as well 20 minutes or 40 minutes.

It is possible to find that time almost any day almost for everyone. Unfortunately, you may need to wake up a bit early some days or go to sleep slightly later, you may have to skip the lunch with your friend and eat it quickly alone instead.

And when you feel you have more energy and time reserved, go on and practice longer, the rule should not limit you and your passion to practice more, it only makes you stay disciplined 😉

2. Track the learning time in an app. "Toggl" is a good option. ⏱

Report by one of the developers I've been helping to. She's been really determined to master the frontend.

Tracking time may seem controversial. The benefits of this technique may not be apparent, so let me explain.

It helps you to identify inconsistent learning (see the first rule). You open the timer's report on Sunday and now you have a pretty clear picture of how the week went for you.

Did you manage to practice consistently? Which days did you put more time? Why? Which days less? Why? What topics were the most challenging? Should you go over them again in the upcoming week? This way you not only make sure you work hard but also guarantee you are working smart.

But above all, it may stop you from quitting. For someone like me, it is a dealbreaker.

One day you may get to a point when you feel like you want to quit. It is okay, it's common. In my practice, it often happens when a learner (me included) already gets to some logical "midpoint" of the learning process.

It is a stage when you already have quite a few knowledge on the subject, for example, frontend development, but it is not enough to let you achieve your primary goal (i.e. find a job, build some specific project, finish a coding challenge, etc).

On that day, opening the timer app, and seeing how bloody many hours you put into the craft so far can be exceptionally refreshing to the degree that you get a thought like "Screew it! I invested so much time and effort into this, the heck I will make that time wasted for nothing."

3. Find a mentor. Going to local meetups or joining Slack communities (pandemic way) is helpful for that. 🧔👱‍♀️

Do. Or do not. There's no try.

This advice helps immensely. But I would like to say that having a mentor does not make you less or more self-taught. It is true if you properly consider who the mentors are and what they here for.

— Mentor is not supposed to teach you. Yes, you still supposed to learn on your own. There are many experienced and qualified teachers for that, and, frankly speaking, your mentor may not have strong skills in teaching itself (though it is helpful when they have). Rather expect this person, when asked, point you to Google if he or she knows that the subject is trivial and you are capable of finding an answer yourself. It is actually a pretty important skill you need and your mentor most likely thinks the same.

— Mentor is not your curriculum developer. A mentor can advise you which subjects you should focus on or which to ignore temporarily. They can help you prioritize building some skills beforehand (for example, get a touch of Git after familiarizing with HTML & CSS), but they are not responsible for building your learning plan. They may give you a hand on that, but I wouldn't expect them to do everything here for you. To be self-taught, you need to learn how to plan your learning.

So, what are the mentors for?

They are here to help to dissemble challenging concepts after you tried to grasp them through courses, books, or articles. Some topics, e.g. the mentioned Promises or async/await syntax, are harder than the other, e.g. if statement. The mentor may ask relevant questions to understand how well you understand the subject, figure out where are weak points in your compression, discuss/explain those and provide you useful materials to defy the subject again ⚔

They also help you to stay engaged. For example, they can discuss with you the Javascript news, share a funny story from work - when they were addressing a recently introduced colleague by the wrong name the whole week... not so funny, actually. Or simply make a harmless joke on you about the last mistake you made during solving a coding challenge (a sense of humor is essential to high self-esteem).

And the last, but not least. The mentor shares with you his/her experience. It can be strictly related to tech, for example through code reviews and pair programming. Or it can be outside of the tech scope, like self-management traits, seeking for a job, writing articles.

It also may be related to highly personal things. But you need to trust your mentor with this, and vice versa, the mentor has to demonstrate trustworthiness. Work and your personal life are often so intertwined, that whatever happens in the one, affects the other. We are human beings and it is normal, but sometimes it may affect you quite strongly, so it is worth asking your mentor advice if you feel you trust them.

I want to share a project that I and my partner have been working on for a while.

We came up with a challenging project to help junior frontend developers that need to showcase their skills and want to build a portfolio to ease the problem of getting a job in the industry.

You can check out it at https://banda.works/housework-undoer.

Housework Undoer is a project organized into separate tasks through which you will build a frontend app to help our (imaginary) friend Jack.

Housework Undoer's app screens

See full size image

Thank you for your time and have a productive day! 💪

Do you need a portfolio to get a job as a junior developer?

Vitaly Krenel — Sat, 11 Jul 2020 04:54:17 +0000

TL;DR.

It depends. There are definitely some paths you could choose to go and start without a portfolio. But by having a decent portfolio (doesn't really matter pet or business projects) you making the task of getting an interesting and well-paid job significantly easier.

If you don't have any project yet or looking for it, below I have a personal story you may find something to learn from and a nice-looking project you could build to add to your portfolio (don't worry, it's free). See you around.

The beginning

Hey. My name is Vitaly. I've been working here and there as a developer for around 6 years. I started as an I-will-do-any-web-related-thing freelancer in my hometown (focusing mostly on design, PHP websites, and CMS engines) and later I moved to a more challenging backend and frontend development.

Initially, I had basic web development skills. I primarily raised those while making a few game-related websites with my friend (you could earn some money on those, especially when you like games yourself and know well game's audience). We had a few experiments but those weren't particularly successful, we split and I went for freelancing.

Later on, I found a mentor. The big guy helped me to hone my skills into something more tailored. Having such a person behind my back immensely boosted my determination and the desire to work hard. I wanted to impress him after all.

When I was starting my "freelancing career", I had neither enough experience nor outstanding projects to prove that I had a decent skillset. On top of that, I was quite young - barely 16 years old. Now you probably can imagine the skepticism people had when I was offering my services.

Still, I didn't care much and had enough reasons to ignore the doubtful looks. I would say that it is one of the most important lessons - to ignore skeptical people, - even though it sounds pretentious.

Lights, camera, action

With all those assets, I had a few strategies to get on the market: either doing random projects providing the best quality I could - I had to dump the price to lure companies in spite of high risks involved with schoolboy doing their projects - or ask people who already knew me (and trusted me) whether they had some work. I tried both. For sure, there were other options as well, but these two I was mostly focused on.

During that time, I was taking on any project (including design ones, like creating promo wall posters, etc.) that I could reach.

One day, my mentor introduced me to a guy that was a media website owner that occasionally had side projects with local companies, including web development endeavors. I ended up doing a few projects for him, which helped me to raise credibility in the eyes of local businesses eventually.

I was working as hard as I could (while still managing to study at school, so that would be I was working at nights) towards quite a reasonable goal for that time.

All those struggling were dedicated to building a stable source of income. I was trying to gather a pool of clients that trusted me and my work and would be willing to collaborate with me again in the future. I staked on the fact, that they would be willing to introduce me to their partners when those would start any web-related project (and with that expanding my client pool further).

As it often happens, that idea failed. But not in an apparent way I imagined it would.

Couldn't raise the bar

Taking on every possible project and at the same time keeping low prices got me locked into a nasty situation. I was spending my time resources quite inefficiently and even though I built a portfolio of projects, almost all of them were admittedly shitty (pardon me). I couldn't really impress a big company with those.

I built a client base and earned some status for being trustworthy, started collaborating with local web development studio, learned a lot of things, many of those were beyond development subject, like communication, design and especially common wisdom (you ask for advance payment when you don't know the client).

Nonetheless, I felt that I couldn't raise the bar. Neither professionally - getting on huge and challenging enough projects - nor financially - significantly increasing my income.

What's probably even worse, my skills were scattered around all areas. I didn't have any primary area of expertise. I was quite okay at everything but was great at nothing. I invested more than 2 years into that, but the return was not exactly what I expected.

Anyway, the school finished, I moved to another city, started a bachelor's degree. Next year and a half I'll keep behind the curtains (as they are irrelevant to the subject), but I have to say that throughout that time, I revised my strategy, quitted the university to have as many resources as I could and shifted the focus from the freelance market to tech companies.

Freelance was great. It still is, especially for people who love to have a lot of autonomy in their work. I'm occasionally taking on projects.

But at that time, I could find ways I would be able to go on without scaling (to meet my financial expectations) and I still wanted to get more of "hardcore" engineering experiences 🤘.

Interviewing process

I had worked for 2 companies so far, the one being a software development outsourcing company and the other being a startup. The startup gave me an especially valuable experience where I had quite diverse tasks to solve. That seems to be the nature of startups - diversity.

So if you are tolerable to risks (which I happened to be after working as a chaotical freelancer) and want to work with different things (quite often from scratch), I recommend you trying out a startup instead of a huge tech company. Though keep in mind, that I mentioned risks intentionally - there's a high chance of startup failing (they say, 9 out of 10 startups fail, never had a chance to check the stats behind this number).

In that startup, I have also had a chance to participate in the hiring process.

It was quite enlightening to see that there are quite a few junior devs that do not really have projects they can share to showcase their skill set. Instead of trying to impress through talking and persuasion, those developers could have taken out a few projects to eliminate the doubt in the looks of interviewers.

I do not diminish the ability to speak or the fact that you still should demonstrate your personal traits and character through the interview. But to prove your skills, a couple of well-built pet projects would work more efficiently and would more likely to increase your chances than letting interviewers examine you through their own assignments and questions.

You will be playing on your own field, so to speak, if you open your project and start telling what challenges you had to overcome while building it.

As I said that experience was quite enlightening for me and I sadly realized that I personally failed to build a decent portfolio at the beginning. I should have done it, but I didn't. And that hardened my life and I repeatedly had to learn how to persuade people, instead of focusing on building projects so companies would not be able to ignore me and would be willing to hire me.

Afterthoughts

I can conclude that It turned out well for me after all, but there had been so many trials and errors before I reached the financial and professional levels I was aiming for. It is not that I went the wrong path, but rather I chose the least optimal one if we consider my goal of getting into high paid but at the same time challenging engineering projects.

These days I'm involved in mentoring junior devs looking for jobs. I'm simply trying to share the experience I've collected so far as in the beginning my mentor did for me.

I'm again and again seeing the pattern when companies are less willing to hire devs (or even reluctant to invite for an interview) without some projects behind. Some are okay, they usually provide their own assignment as a part of their initial filtering process, but quite a few companies are not.

I won't bluntly say for HRs and the agency as I have mere experience with their screening procedures, but I believe it is much easier to catch their eyes as well when you have a couple of decent projects in your portfolio.

As a final note, I want to share a project that I and my partner have been working on for a while.

We came up with a challenging project assignment to help junior frontend developers that need to showcase their skills and want to build a portfolio to ease the problem of getting a job in the industry.

You can check out it at https://banda.works/housework-undoer.

It is basically a project assignment through which you will build a frontend app (called "Housework Undoer") to help our (imaginary) friend Jack.

Housework Undoer's app screens

Thank you for your time and have a productive day!

Pragmatic developer: Learn architecture and design patterns. Using ORM and ActiveRecord

Vitaly Krenel — Mon, 02 Mar 2020 06:44:38 +0000

Table of content:

Intro
What is a domain model?
Data persistence
ORM as a layer of abstraction
ActiveRecord pattern to persist application data changes
- Pros and Cons of ActiveRecord
ActiveRecord in the wild. Implementation examples
ActiveRecord pattern in frontend
Summary

Intro

This section is the series introduction. If you want to start with the article immediately, just read last 2 paragraphs to understand the subject and go ahead.

Building a digital product is not easy. There are a lot of distinct challenges involved. Among those are code architecture challenges. As engineers, we strive to write beautiful code. As product creators, we strive to write code that immediately resolves the problem.

Unfortunately, you cannot solely write beautiful code - you will spend so much time polishing one small piece, that the whole sense of creating a product will be lost. Instead of growing a product that eliminates the real problem of your customers, you will focus on discussing all the time whether you need to put a condition outside or inside a function.

At the same time, you cannot write only code that immediately solves the problem - you will be dragged repeatedly into dealing with small annoying bugs, will have to write a huge bunch of boilerplate code just to introduce something and that's mostly because of your inability to foresee and prepare to scale. I won't even say about the amount of effort needed to maintain such a codebase and, what for me is even more important, the feeling you experience working on something you find ugly.

Instead, I believe, that to be an effective developer capable of both creating and maintaining a product, you need to write pragmatic code. Pragmatic, as I see it, means sometimes to build a foundation beforehand. Sometimes to introduce a proper solution only on-demand, when you see an actual problem getting back over and over. Sometimes ditch a proper solution, fix the problem straight away and forget it for the time being. Overall, it's about being reasonable, realistic and not doing what is unnecessary, but still, being an engineer that favors elegance and beauty. No matter how controversial this statement sounds.

And here comes the first trouble. To be a pragmatic developer, you need to know a lot of possible solutions that you can use in specific cases. Otherwise, you'll go with what you have, without any consideration about what would be appropriate in that exact case.

This article is part of the intended series on architecture concepts and design patterns that I'm interested in, have some knowledge or experience with and would like to share so you could be more pragmatic having extra options to choose from.

The content of the series, in my mind, is suitable for developers with 2-3 years of relatively diverse development experience. I will assume you tried both frontend and backend web development to some adequate degree. If you are in the industry only for a year or even less but is "ahead of a crowd", you should still be able to follow along.

I mainly use Typescript-like syntax for code examples as a compromise between having well-expressed code pieces and those that can be digested by devs with different programming language backgrounds. In some cases, it may not be a completely valid code piece with some required parts being stripped.

The first article is focusing on the domain and data persistence. I cover the ORM concept and specifically the wide-spread ActiveRecord pattern as one of the solutions that may be used to keep the persistence layer (the one responsible for storing and retrieving application data) relatively simple and thus maintainable.

As I already typed down a small self-composed lyrical essay, we can finally start with domain field and domain model concepts that are, in some sense, an underlying part of any application's persistence.

What is a domain model?

In any application, we can find some kind of a domain model - a conceptual model of any specific field represented by entities, their behaviors, and relationships between them.

To create a domain model you need to explore the domain field. You do not need to understand and know the whole field in the finest details, it is usually enough to understand a part of the field (basically, some of the terms and concepts used there). Sometimes, you may have a domain expert around which you can consult with. Sometimes, you have to look for information yourself.

Let's consider driver education as an example of the domain field. I assume, that any driving school has several instructors - then, we can say that a driving instructor is a domain entity.

An instructor has a name, gender, a list of licenses they teach, some information about their driving experience.

class DrivingInstructor {
  firstName: string;
  lastName: string;
  gender: string;
  teachableLicenses: License[];
  yearsOfDrivingExperience: number;
}

This DrivingInstructor class represents one specific entity and is a part of our domain model.

You are not obliged to use classes to design the domain, simple literal objects with factory functions are okay. Moreover, this approach is quite convenient in FP or FP-like programming styles, as the paradigm encourages usage of pure functions and immutability instead of classes (which favor mutability instead).

interface DrivingInstructor = {
  firstName: string;
  lastName: string;
  gender: string;
  teachableLicenses: License[];
  yearsOfDrivingExperience: number;
};

const createDrivingInstructor = ({
  firstName,
  lastName,
  gender,
  /* ... */
}): DrivingInstructor => ({
  firstName,
  lastName,
  gender,
  /* ... */
});

There can be many different entities within the domain - basically, any real-life thing, e.g. an employee, banking account, a cup of coffee, article, etc., can be a domain entity. There can be 5 or several dozens of entities - it depends on the developer's approach and the domain field complexity.

To practice a bit further designing the domain model, take a restaurant business. There, you would have a reservation as a domain field concept.

class Reservation {
  id: number;
  date: Date;
  seatingAreaId: number;
  guestsCount: number;
  ownerId: number;
  status: ReservationStatus;
}

In this case, the reservation has relationships with several entities, more specifically "has-a" relationship with Seating Area (probably a table or a room) and belongs to the Reservation Owner i.e. the Owner has a "has-a" relationship with Reservation.

If you are not familiar with "has a" relationship take a look at the "Aggregation" section in this wiki article.

What about behavior? When you book a table in a restaurant, there's usually an option to cancel the reservation in case you have changed your mind (or those, you were planning to go with, did :sigh). So this cancel operation is the behavior available for the Reservation.

class Reservation {
  /* ... */

  void cancel() {
    if (this.status !== ReservationStatus.FINISHED) {
      this.status = ReservationStatus.CANCEL;
    }
  }

Behavior is any business-related logic. Usually, it is a method or a function that changes the state of an entity (like cancel method), calculates something (e.g. .transfer(destinationAccount) method in a banking app) or performs some validations.

We discussed what are the domain and domain entities, but those are only the concepts that start to make sense when they have some actual data packed into them. We still need to discuss how to approach storing that data and restoring it when we want. These concerns are covered by the persistence layer.

Data persistence

In general, to persist the data means to retrieve application data after a program execution has started and to store some data after the program has finished.

In the frontend case, opening a tab with a web app is the start and closing that tab is the end. With backend, it may differ from language to language, but we can assume that receiving an HTTP request is the start and sending the response back (or closing the connection) is the end.

Usually, you want the application data to be available after the execution is ended. That makes the persistence-related code an important part of the codebase. If it fails often or is bug-prone, you may lose the data. Moreover, asking users to do something twice, may easily annoy them and turn away from our products (which is, you know, undesirable from a business perspective).

How would you deal with it: how would you organize the code responsible for persistence? The very basic approach may be to use SQL statements throughout our code each time we need to put to or pull from a database:

const reservation = new Reservation({
  ownerId: 13,
  seatingAreaId: 8,
  guestsCount: 3,
  date: new Date('2019-10-19 17:30'),
  status: ReservationStatus.PENDING,
});

database.prepareQuery(`
  INSERT INTO reservations (
    Id, OwnerId, SeatingAreaId, GuestsCount, Date, Status
  ) VALUES (
    :id, :ownerId, :seatingAreaId, :guestsCount, :date, :status
  )`,
  reservation,
).execute();

This approach is a way to go in small apps or those that are in MVP state, but, you can guess, it is not scalable.

A more appropriate solution to the problem can be to introduce an ORM.

ORM as a layer of abstraction

ORM (Object Relational Mapping) is the concept of mapping existent database records to your application. So instead of performing database operations manually (the same way I did in the example above), you would represent different database operations through different objects and method calls.

ORM is a pattern. But quite often in spoken language when people say "ORM" they mean a specific library (or a tool) that covers database abstraction concern in their language of choice. For example, in PHP there are Eloquent and Doctrine ORMs. In Ruby on Rails - ActiveRecord (it is both the name of the pattern and Rails' ORM). Python has SQLAlchemy and Django ORM.

So to prevent confusion, I suggest you perceive ORM as a layer that abstracts database-related operations and is a bridge between database records and your domain entities classes (that are called "models" in MVC or MV* architecture styles).

ORM may be built with the help of different patterns. And there are a few that may change how you would persist the domain entities. In this article, I focus on the ActiveRecord pattern.

ActiveRecord pattern to persist application data changes

an object that wraps a record in a database table, not only carries both data and behavior but also encapsulates the database access. See ActiveRecord's definition by Martin Fowler

Highlighting the most important from that definition, we can get two main points:
1) your domain objects are mapped to the database records;
2) they [objects] handle the database access themselves.

class ActiveRecord {
  static tableName: string;
  static schema: Schema;
  static isInitialized: Boolean;

  constructor(...entityProperties) {
    this.init();
    this.defineFields();

    for ([propertyName, propertyValue] of Object.pairs(entityProperties)) {
      this[propertyName] = propertyValue;
    }
  }

  /**
    * Find related table in the database and retrieve its schema (meta
    * information) like column names, their types, nullable or not, etc.
    */
  static private init() {
    if (isEmpty(this.tableName)) {
      // Guess table name from the class e.g. 'Reservation' class
      // can be converted to 'reservations' table name
      this.tableName = Database.guessTable(this.constructor.name);
    }

    if (isEmpty(this.schema)) {
      this.retrieveTableSchema();
    }

    this.isInitialized = true;
  }

  /**
    * Retrieve table meta information that exists in the corresponding table
    */
  private retrieveTableSchema() {
    this.schema = Database.retrieveSchema(this.tableName);
  }

  /**
    * Create a new field in the object for each table column,
    * so they can be populated later with real data.
    */
  private defineFields() {
    for (column of this.meta) {
      // Convert column name to field name and initialize a field
      // on the object, e.g. for 'owner_id' column, reservation object
      // will have 'ownerId' field
      const fieldName = convertToCamelCase(column.name);
      this[fieldName] = null;
    }
  }

  /*
   * Persist the entity object to the database
   */
  public save(): void {
    // Covert back from camelCase to syntax that was used in table column names
    // the resulting object can be pushed to the database to an existing
    // record or add a new one
    const tableRecord = mapFieldsToColumns(
      this.fields,
      this.schema,
    );

    Database.insertOrUpdate(this.tableName, tableRecord);
  }

  public delete(): Boolean {
    return Database.delete(this.tableName, this.fields.id);
  }

  public static find(params): any {
    if (this.isInitialized === false) {
      this.init();
    }

    const searchableRecord = mapParamFieldsToColumns(
      this.schema,
      params,
    );

    const record = Database.find(this.tableName, searchableRecord);
    const entityProperties = mapToCamelCase(record);

    // Static methods in JS recieves class itself as 'this' value
    // So this would translate to new Reservation(...entityProperties)
    return new this(...entityProperties);
  }

  /**
    * Count records in the corresponding table
    */
  public static count(): Number { /* ... */ }

  /**
    * Reset the whole table
    */
  public static reset(): Boolean { /* ... */ }
}

Now any domain entity extending this ActiveRecord class will be able to work with the database on its own.

class Reservation extends ActiveRecord {
  // Entity fields are implicitly declared when a new object
  // is created or pulled from the database

  // id: number;
  // date: Date;
  // seatingAreaId: number;
  // guestsCount: number;
  // ownerId: number;
  // status: ReservationStatus;

  confirm(): void {
    this.status = ReservationStatus.CONFIRMED;
  }
}

const reservation = new Reservation({
  reservationOwnerId: 13,
  seatingAreaId: 8,
  guestsCount: 3,
  date: new Date('2019-10-19 17:30'),
  status: ReservationStatus.PENDING
});

// Manager confirmed the reservation, but the guest
// has asked to reschedule the reservation time until 19:30
reservation.confirm();
reservation.date = new Date('2019-10-19 17:30');
reservation.save();

With ActiveRecord, all additional database access code required for the entity should be kept within its class. You can add new methods to perform other database operations (e.g. a findAllByOwner).

class Reservation extends ActiveRecord {
  /* ... */

  static findAllByOwner(ownerId) {
    Database.prepareQuery(`
      SELECT * FROM ${this.tableName} WHERE ownerId = :ownerId`,
      ownerId,
    ).execute();
  }
}

In real practice, instead of plain Database calls you would use something like Builder pattern to dynamically create a query and execute it.

You may wonder how to use the approach I've brought up in the first part of the article - those plain domain objects with create factory function.

Because of ActiveRecord is an object-oriented design pattern, it is quite hard to adopt it in the context of functional programming. So it won't work straight away.

At the same time, it doesn't mean that other patterns initially authored in the context of OOP cannot be adopted in different contexts, especially with languages having both FP and OO elements (like JavaScript or Scala).

I'll cover the approach of building the persistence layer with those plain domain objects in one of the next articles.

I think, now we can narrow our discussion to ActiveRecord's strong and weak sides. This knowledge directly affects your ability to determine whether you encountered a suitable use case for the pattern.

Pros and Cons of ActiveRecord

Any pattern is a tool and each tool has its own strong and weak sides. If you are going to implement any pattern or, what happens constantly, use a library that implements one, I suggest you learning those sides. This way you will be more likely to pick a proper solution that fits your needs.

There are a few strong and weak spots of the pattern I've noticed in my practice. Let's start with strong ones.

ActiveRecord is self-descriptive. Because of the close relationship between models and database tables, it’s easy to look into a project, examine its database schema, and you will have a decent level of understanding of the project.
Some of the existent ORM libraries let you declare a list of columns (or properties) available in the corresponding table within the model class straight away. This way you'll have a complete definition of the models, relationships and business logic in one place (e.g. Typeorm, Laravel). Other provide external schema file (or at least migrations) where you can discover database tables structure (e.g. Rails).
As this pattern gathers domain data, logic and database access together you can think about them as one conceptual piece that makes your code relatively simple. In most cases, you won't need to inject anything but a domain model to perform some business logic.

On the other hand, some disadvantages are deriving from both those points:

On its own, the pattern encourages tight coupling between domain objects and your database. Every domain object knows about the database, tables, and schemas. This statement also implies that the pattern violates the single responsibility principle.
Because the domain objects are mapped to the database schema, project refactoring becomes more difficult as changes in one, either domain or database design, will force you to adjust the other.
It also increases the complexity of the logic in your domain objects as they will have to deal with both business logic concerns as well as database access (persistence concerns). A lot of relationships, inheritance, sophisticated entities and complex queries may make your code quite messy if you do not adapt patterns to tackle those problems.

ActiveRecord in the wild

There are many implementations of the pattern in different languages and frameworks of choice. A lot of popular frameworks built their ORM layer with ActiveRecord usage.

A small list of those with the link to the GitHub repo where you may check out their implementations. I recommend doing that if you're either a relatively experienced developer - your experience most likely precedes theoretical understanding, so it is useful for professional growth to see how other devs solve programming problems - or a developer specifically digs into project design and architecture and likes the subject.

Laravel - one of the most popular frameworks in PHP. Laravel's ORM system is called Eloquent and it provides the ActiveRecord implementation through its Model class.
- Docs: https://laravel.com/docs/6.x/eloquent
- Sources: https://github.com/illuminate/.../Eloquent
Ruby on Rails - quite old but sexy framework in Ruby. Rails ORM is called ActiveRecord (the same way the pattern is named), so in the Ruby community, you can often hear people referencing ActiveRecord as an ORM instead of a pattern. Don't be confused: those statements are simply context-aware.
- Docs: https://guides.rubyonrails.org/active_record_basics.html
- Sources: https://github.com/rails/.../activerecord

There are also ActiveModel and ActiveResource in Rails but those are different concepts, not related to database or ORM.

Typeorm - great ORM written in JavaScript (TypeScript) that can work both on client and server sides (pretty much everywhere where you can run JavaScript). It is quite interesting how it adopts the idea of ES decorators (@decorateSomething) to declare an entity and to provide information about available properties.
- Docs: https://typeorm.io/#/active-record-data-mapper
- Sources: https://github.com/typeorm/.../repository/BaseEntity.ts. I recommend starting from there and additionally check out the whole repository folder as well.

ActiveRecord pattern in frontend

This section is speculation combined with my general professional experience. I have never used this approach in production so take my words with a grain of salt. The idea of applying development concepts and patterns in different contexts is interesting to me. I encourage you to share ideas and experiences on the subject if you encountered or tried this pattern in your frontend practice. You may share something that will be valuable to other devs and helps them. It will boost your karma 😉.

One interesting moment is that this pattern is not applied frequently in the frontend, even though some frontend applications resemble UI for database CRUD operations.

One of the ActiveRecord examples I encountered in frontend development practice is BackboneJS, specifically, Model and Collection components. The model or a collection of models can be saved, destroyed, fetched and synced between client and server.

const Book = Backbone.Model.extend({
    defaults() {
      return {
        title: ''
        authorId: null,
        readStatus: ReadStatus.NOT_STARTED,
      };
    },

    startReading() {
      this.save({ readStatus: ReadStatus.READING });
    }
});

const Books = Backbone.Collection.extend({
  url: '/api/v1/books',
});

// Fetch list of user's books from endpoint /api/v1/books
Books.fetch();

For quite a while Backbone is consider to be a legacy tool (probably for more than 5 years). But it is still worth learning how some problems were addressed with different patterns, even though the Backbone is no longer a tool-of-choice.

If you are a front-end engineer that cares about architecture, maintainability, and scalability of your solutions, it is worth in general exploring different frameworks like Backbone, React, Meteor, etc. They all adopted different patterns to solve common problems of building an effective web app architecture.

Another interesting proof of concept is ActiveResource.js library. More on the library you can read in introduction post on TopTal.com. I will provide a small summary (that pretty much can be found in the article) of the interface that the library empowers your domain entities with.

// Basic methods to retrive either a collection of or only one record
let users = await User.all();
let user = await User.first();
user = await User.last();

// Get a first record
user = await User.find('1');
// Find a record with the specified attribute
user = await User.findBy({ firstName: 'Jack' });

user.firstName = 'Jackie';

// Persist user changes to the server or handle the error if edit is not possible
try {
  await user.save();
} catch (userEditError) {
  // ...
}

/**
  * More complex example quering user records.
  * .includes() forces AR to fetch also user-related notifications 
  * (example of relationship).
  * .select() asks API to return only email and notifications 
  * (with message and createdAt) attributes.
  */
users = await User
  .includes('notifications')
  .select('email', { notifications: ['message', 'createdAt'] })
  .order({ email: 'desc' })
  .where({ admin: false })
  .perPage(10)
  .page(3)
  .all();

Under the hood, these method calls are constructing a request to your API endpoint conforming JSON:API specification.

If you are not familiar with JSON:API, it is pretty much just a specification for REST APIs providing concrete rules for structuring JSON-based API responses. Check out project's documentation for more information and examples.

Quite interesting, that ActiveResource.js originates from Rails' ActiveResource class that provided similar functionality for backend models that are backed by other API providers (and not database). Backbone's Model and Collection have a similar background as they were inspired by Rails ActiveRecord ORM.

Nonetheless, as I said before, the ActiveRecord pattern is not frequently applied in the frontend world. One of the reasons, in my opinion, is that to implement ActiveRecord in client-side code your API (or APIs in more complex cases) should conform to some specification or convention and be consistent. Otherwise, you won't be able to reliably parse the responses on the client-side without writing a lot of boilerplate code for each entity endpoint.

Using ActiveRecord would also mean that you (as a frontend engineer) would build domain models on client-side (or at least some form of them) and use them, which raises a question on how to manage those models with conjunction to modern frontend stores like Redux or Ngrx. Especially when libraries encourage FP-like programming style which will force you to serialize them back and forth all the time (which doesn't seem to be sustainable) so the view layer would be notified about data changes.

Though it's still should be possible to use such domain models with observable-based store system, like MobX. As all model changes will be observed, you can pretty easily watch for those in view layer and, when needed, to perform actions to persist an updated model (or collection of models) through the model instance.

Summary

It seems to me, you've read a lot. Starting with the domain model concept being a part of any application (either implicitly or explicitly), we learned that it is represented by entities, their behaviors, and relationships.

The entities encapsulate application data that has to be persisted, and we need to manage the persistence code complexity to keep it reliable (fewer bugs, more safety) and maintainable.

To achieve that, we introduced ORM as an abstraction from plain database calls and queries and used the ActiveRecord pattern to provide database access for our domain entities so they could be persisted when needed. We also discussed the advantages and disadvantages of ActiveRecord, to have a slightly clearer picture about cases when it will be appropriate to use the pattern.

The last section was more like an incomplete study of how one may apply the ActiveRecord pattern in frontend development practice.

I hope you'll find the content of the article valuable on your path of becoming a pragmatic developer. I intend to continue creating such content and want to explore another part of a developer that can be called a "product creator". In my opinion, that identity should be improved and grown alongside with your engineer side.

I would appreciate your feedback after reading, whether you find the article content (architecture and design patterns) useful to you and how do you feel about long-read posts on similar subjects.