JS be fun!

I was recently at the job interview and the interviewer asked me about things I were knowledgeable, yet I didn't get a job from a very reason the way I answered his questions. I made a rookie mistake: I just tried to say everything I know about the thing in question. This caused my answer to be chaotic and not very to the point. My interviewer listened to me, so I thought that I made a good impression. I knew things after all! And few day later the rejection letter came to me. It contained the thorough feedback. I think it's good to have feedback like this, and I'm glad this company wrote it. However, to my surprise, I was rejected from the very reason I hoped to get through. It was communicated to me that I had problems with the clear explanation of technical matters. And they feared that I wouldn't manage to work in environment where there's a need of constant explaining things to many people, especially ones with smaller technical knowledge. What did I do w...

Well. Imagine that I would have simple microservice that is small Express application that serves data from DB and transforms it. First I would think about proper design of code. I would split code into: initialization part (creating Express app) - smoke tests would be sufficient Express endpoints - they will be set appropriate headers and integrate logic and DB. I would tests more overally - if headers are correct etc. logic - this is meat, so I would test more thorougly this. Logic would be probably in pure functions. Easy to test. (that's one of reasons I don't want to put to much logic in endpoints themselves because they are harder to test). wrapper for DB - I would test e2e with some kind of development database in play. Maybe I would also make some kind of automatically generated tests for endpoints. I mean. I would already test logic so no need to duplicate code, but to ensure that endpoint really returns logic. I would probably make functions l...

From what I observed React context is used in many ways: As simple value (e.g. string, number, boolean) As object As immutable object (i.e. if you want to change something in context you trigger appropriate update to component which render Context.Provider As mutable object (i.e. if you want to change something in context, you mutate context directly. I usually work this way that have main app context which is mutable and contains some "global" variables and some methods for making global changes. I think mutable React context is harder to maintain. And context always sounded like some escape hatch for access/write to global state. And I usually won't have too many contexts. In small app there would be one React context. In bigger apps I could think about some others, for some specific parts of app or maybe for some specific aspect of app (e.g. UserContext, ToDoContext etc.) And context for me means usually object. In React do...

You don't need Redux or any management system in React. You know this, right? Right? But seriously people usually when they don't use state manager, they just use useState and context. And it can be sufficient. But not always. Sometimes you need global state management, but Redux and different state managers are just inconvenient They force immutability (you can mitigate it with libraries like immer, but still). They often force you to use some kind of actions What's your options? If there was a way that would allow to use plain JS objects and classes for state management. Wait? Do I mean Mobx? Well, conceptually, yes. But the truth is you don't need ANY library for this. Mobx just wires JS objects to updates. But the thing is you can do this your self. Just write normal JS classes and put reactivity into them. You can know think that's reinventing the wheel, but I will say it's super simple: class Entity { subscribers = []; state = {}; ...

Entity... it's a word that it's often related with Domain Driven Design, but I won't write specifically about DDD. What I want to write, can be used without DDD approach. I think DDD is somewhat conceptual heavy and it's often useful to use terms popularized by DDD but without all this weight. So. What's entity? Let's assume it's a JavaScript class (actually it doesn't have to be a class, it's more conceptual term, but now I assume some specific implementation of this). So... each JavaScript class? No. It's more like something that has specific identity. e.g. User, Product. Usually you have many things of some type (e.g. many users), but this concrete user (represents in database by specific row, but in app you would create instance of User class for example). On the other hand if you have something that is more of a utility class - e.g. imagine that you have Theme class with colors, backgrounds - this thing is probably not entity (thou...

how to organize React project to ensure maintainability? separate configuration - instead of putting all in your "normal" files (e.g. files with React components), it's better to put "configurable" things in separate file. What's are configurable things? E.g. urls for API endpoints, route names, translations etc. dev mode - it's useful also separate your configuration for debugging or testing from the production one. You could also have some feature flags somewhere in your app to enable devs to comfortable debugging e.g. special buttons for doing something useful for programmer, that has no sense whatsoever in production mode. Sometimes it's useful to have some "sandbox" views. separate components into files - rule of thumb can be thought as "each component in different file" but this has not always to be true. Sometimes you could put multiple smaller components in one file if they are related/part...

I'm learning Nest.js. I'm going to have job interview and this job demands Nest.js. Well, before I had quick contact with Nest.js and I thought "this is overengineered". And when returning, I still think this is a case. I think Nest.js is heavily engineered framework and I wonder "why is it popular at all?". I mean Angular is frowned upon, and Nest.js is like Angular. I think though there's some added value in Nest.js and I think this value lies in standardizing your code. Nest.js is a framework so you have to put your code in predetermined places. And this alone saves case of Nest.js. This framework doesn't solve technical problems, this framework solves problems with people having various opinions (because it is quite opinionated). And people, if you are programmer, are usually your main problem to solve.

Few notes on how to make SPA: start with model. Don't care about GUI on the very beginning. Start writing basic classes in pure JavaScript and write unit tests for it. E.g. if you do Todo List, make some classes like Todo, TodoList etc. Think in concepts of domain knowledge rather than GUI. but remember that your models should be reactive(or it should be easy to add reactivity). You can start right away with reactive code using some reactive library like Redux or Mobx, or you can add this reactivity later (simple addon is using some kind of observer pattern - e.g. via EventTarget It's useful to have same models on backend and frontend but it's not always be the case. Anyway, think also how you will connect backend with frontend and how you implement reactivity For GUI you can use library with component paradigm e.g. React, Vue, Angular. Think on how you will connect and integrate your models with visual components. Do models contain everything you will need? Or d...

So you wanna make 2D platformer game? Here are tips for you: 1. You need to check collisions between objects. Treat each object as a rectangle and check coordinates to examine if there is overlap. If there is, perform pixel based detection (there can be transparent pixels). 2. You can use tile map for making game levels 3. Objects can have "platform" property. If platform == null, they are falling because of gravity. But if objects is falling you still need to examine if there's collision with a platform. 4. To make various bonuses/collectable items that player can collect - make inventory object where each property is value of some bonus or feature: {energy: 100, gold: 10, spells: 20} // player properties and make bonus object look like this: {energy: 10, gold: 2} // bonus that adds 10 energy and 2 gold. you can also make some negative bonuses (e.g. poisons, thorns) {energy: -10, xp: 2} // it takes 10 points of energy, though it gives you 2 xp. Read also about multisets...

tile map it allows for dividing big world into small pieces (e.g. into squares or hexagons). It makes programming games a lot easier. You could easily detect if something is standing or neighboring something else (e.g. if unit is standing on a road) links: https://www.redblobgames.com/grids/hexagons/ path finding it allows units for finding path from A to B, even when path is not obvious (e.g. if you need to go around obstacles, move across corridors etc.) Redblobgames has articles about it: https://www.redblobgames.com/pathfinding/a-star/introduction.html events/commands/messages Instead of directly calling method of given object, put data of "what you would like to happen" in special command object. This allows for better decoupling and for easier managing side-effects. https://gameprogrammingpatterns.com/command.html state machines and other asynchronous patterns - it's often needed for making AI for NPCs, having som...

JavaScript is a universal language, so it can be used for making games. This way you could create game which can run in browser (though it's not only way - you could use WebAsssembly and you won't be limited to JavaScript) But how to enter JS gamedev space? Try first to make simple games, then more complex. Complexity can have few aspects: graphics - GUI/button based games --> 2D graphics --> 3D graphics logic - very few rules (e.g. snake) --> games with more rules (e.g. platform game) --> whole simulation of the virtual world (strategy games, FPS games etc.) how to learn make graphics: Well, assuming you already know how to make websites in JavaScript I recommend that you first learn making very simple games with simple GUI based graphics - e.g. memory game, jigsaw puzzle, word guessing etc. This kind of games can be done in way you would usually make websites (e.g. using React or even with vanilla DOM) Then you could learn...

As a front-end developer in 2023, you need to become both more specialized and more generalist at the same time. Previously (circa 2005-2010) there was no front-back division and web developers usually also knew how to write HTML, CSS or write simple scripts in JavaScript, often paired with jQuery library. Then (I think it was about 2010?) front-dev development emerged as separated discipline. Front-dev devs became more and more isolated from backend. In following years front-dev and its ecosystem expanded. JavaScript evolved into quite modern and expressive language. New libraries was created like Angulars(1.* and 2+), React, Vue. More and more complex commercial applications would be created by companies. Job market was booming. But because there was more and more competition between companies, modern practices of product development also had to be put in place, because companies needed their products to be more competitive and user-friendly. So there were new roles in teams ...

How to recognize when you're ready for being a senior developer? Well, it can come gradually but there are some signs: You are given more and more responsibility and trust. Well remember that nobody trusted you when you were a junior dev? And they were given to you only some not very important things. As a mid developer you would usually still feel this kind of hierarchy and superiority from more senior developers. And now - when a team trusts you and gives you most important parts of software - this is a sign that other people perceive your seniority. You often mentor other people in team. As a junior dev, you are taught by others, as a mid dev, you're doing your thing, as a senior dev, you help others to be more productive. You're starting to see things in more holistic way, you can take programmer perspective but also business perspective or look from perspective of end user. You become better communicator and help other people on your team to communicate ...

Front-end is often overlooked. People treat it as it would be super trivial or something that is so dirty nobody wants to touch (back-end developers often have this kind of disdain for front-end). When you have such negative views of front-end dev in your team, you would have self full-filling prophecy. The truth is different - front-end in 2023 can be as professional as "real" programming. But you have to treat it seriously. Let's dive in and check if you have things below in your front-end project: people - when you need back-end code, you need back-end developer, when you need front-end, you will need a front-end developer. And you need good developers with strong skills and professional responsibility. obvious things - Git, package.json, probably bundler (e.g. Esbuild, Webpack etc.), CI/CD pipeline for deploying tests - front-end code is still a code, so you can write unit tests for many things in frontend. Though unit testing GUI maybe won't be...

Software architecture needs boundaries. But what does it mean? Well. It means that when you have many things in your app - multiple classes, multiple modules etc. you don't want them to depend freely on each other: But you want something more similar to this: Notice that on both images there are 6 boxes. On the second image though we have clear boundaries of which modules can communicate with which other modules: So basically you could say that I drew aggregates and aggregates roots from DDD(Domain Driven Design), but I think this approach is not limited to DDD. You don't need to practice full blown DDD to create such boundaries in your project. You could similar approach e.g. for separating groups of React components. But what boundaries mean in React app? State - if you're lifting state up, you lift only to the boundary of subtree Props - if you make prop drilling, you limit this practice to boundary of "aggregate" Context - you limi...

If you're a junior developer , don't be afraid of asking questions. How does particular module in project work? There's things that are not on the internet. And other programmers have knowledge you need to be good junior developer. But when you have your answer, write it down, so that you won't be asking the same thing twice. Remember also about internet, documentations, source code, issue tracker... sometimes you don't need to ask if you can check it yourself. But overally asking is way to go. There's many thing specific for project (e.g. requirements) that you won't predict if you don't ask If you're a regular developer , you still will need to ask questions if you don't know something, but you need to be more proactive in your communication. You shouldn't be only focused on your task, but communicate to help other people or to gain insights about project/its progress/implementation details/architecture approach etc. It's time to be m...

Now I'm learning how to make REST API in Next.js It turns out that you have to create route.js/.ts file somewhere in your app folder (even in some deep folder). So it's somewhat like page.jsx/.tsx. In this file you have to export functions that are called same as HTTP method. So if you want to handle POST method, you have to export POST function. And it's pretty easy e.g. import { NextResponse } from 'next/server'; export async function POST(request) { const d = await request.json(); return NextResponse.json({ok: true, d}); } first I coded something like that: const d = await request.json(); return NextResponse.json({ok: true, d: await request.json()}); but this generated error - error TypeError: disturbed at NextRequest.blob (node:internal/deps/undici/undici:1795:21) at NextRequest.text (node:internal/deps/undici/undici:1813:33) at NextRequest.json (node:internal/deps/undici/undici:1817:38) It turns out that you shou...

Learning about sending/receiving HTML forms. I rarely write forms nowadays but it's useful skill to have. Express side Created simple Express application, how could I receive form fields in it? Well, it's not straightforward, I had to use body parser const express = require('express') const bodyParser = require('body-parser') const app = express(); app.use(express.json()) app.use(bodyParser.json()) app.use(bodyParser.urlencoded({extended: true})); app.post('/', (req, res) => { console.log(req.body); res.send('OKEJ!') }); //... Which always seemed strange for me. Few years ago I used Express and I thought maybe in 2023 this could be more simple. I mean, ofc it's few lines of code on beginning of project, but still. Too low level. I kind of expect that such basic thing would work outof the box. HTML side Right now I'm sending this form via HTML but what if I wanted to send via fetch? Well I had problem with sendin...

I'm learning how to create middleware in Next.js app router. https://nextjs.org/docs/app/building-your-application/routing/middleware There's one middleware per project which was WTF for me, but they write that you could put some ifs in your codebase: https://nextjs.org/docs/app/building-your-application/routing/middleware#conditional-statements so maybe it's not a limitation after all. First I used NextResponse.redirect but this changed my URL so I used NextResponse.rewrite so I am returning some content but URL stays the same I haven't play with cookies or headers yet And authentication - big thing to know. Besides I wonder where to put data fetching in my SSG app. I'm making something that read some files on disk and I don't want to fetch same JSON file over and over. I thought maybe I could read data in middleware and pass to views but I think this is not really how you should do it in Next.js (well, there's possibility to pass data to routes...

Testing is one of most misunderstood things in software development. I've seen this many times and this poor understanding of testing often affects negatively on projects. Let's see common flaws: Lack of unit tests and proper discipline around code acceptance - I worked for game company and we had games that were tested only by QA. And there were bugs. Every morning I logged into daily standup and almost everyday half of standup were "what is going from in which version of game" we had many similar games, catered and modified for different countries (regulations etc.) and seasons (e.g. Halloween edition). Moreover programmers ignored bugs during development and delayed fixing them. Testing the implementation. It's common mistake to tests directly everything. People often conflate two things: 100% testing coverage creating separate unit test for every class/function/method Many things can (and should) be tested indirectly. Testin...