Putting it shortly: everything has changed since I last posted here. EVERYTHING.

This blog post is my retrospective on the last 18 months. Personal. Self-healing. Unblocking.

Moved back to Poland

After 6 years of traveling and working remotely, my wife and I decided to come back to Poland. When we left, there was no specific goal. We just wanted to explore and live this life (and we did to the fuuuuuullest and we still are!). Somewhere in the back of our heads there was this idea of finding a better place. An ideal place to settle down. But as it turned out, no place is perfect. Even living in the paradise of Indonesia for 15 months had its flaws

However, the best side effect (or maybe the main effect) of living in several different countries is the new perspective. Being back in Poland now (which is an amazing country) hits completely different than it was those ~7 years ago. I appreciate it 100000 times more. I am constantly amazed by little things that I previously took for granted or didn’t even notice. This gives me a unique perspective on living here and I really appreciate that.

Longer trips and workations will resume, but for now I am proudly calling myself a self-retired digital nomad

Switched to Mac

In mid-2025, I decided to switch to a Mac. I’ve always been a .NET guy, on Windows since 1998 , but my new job eliminated working with legacy desktop stuff, so I could make the move. I bought a 16-inch MacBook M4 Pro with 48GBs of RAM and 512 GBs of disk space. I was a little worried about the disk space, but after ~1 year it’s just enough for me. Just checked and I still have 260GBs of free space (did the cleanup a few days ago though, before that it was around 180 GBs free). My daily toolbox includes Rider, VS Code, .net&npm, Claude Code, 6-10 docker containers and a few smaller local LLMs running in LM Studio.

I wouldn’t believe saying this 2 years ago, but switching to Mac was the best decision ever. There’s even nothing to write about here. It’s just amazing and I can finally work 8-10 hours without charging it – just in time when I retired from full-time nomading

Started working for a fully remote SaaS company

I also started working for an Australian, fully remote SaaS company. We are building a platform for healthcare professionals, mostly from Australia, US and the UK. The teams are distributed all over the world, but we are not a corporation (there’s probably around 90 of us currently, including ~40 engineers).

It’s been challenging for me to move from a software house to working on an actual SaaS product, which comes with more responsibility, but also more possibilities and influence on the product.

AI… AI everywhere

I didn’t want to start with this point, but this is HUGE. When writing my last article here, in December 2024, the only AI I used was probably the tab completion with GitHub Copilot in VS Code. Early days Since then, my working turned upside down.

I hope to write down more about it one day, but TLDR:

I went through different tools (Cursor, Zed) to – for now – settle down with Claude Code and Codex, which I use every day. Today, I write the definitive most of my code with AI. I also research with AI. I’m building features leveraging LLMs, which bring amazing value to the users. I’m thinking much more about the product, the actual usage of it, the value for the end users, the architecture, security, deployments than about which C# features to use or how to structure the code on the lowest level. I don’t remember when I last visited StackOverflow

And it’s not only work! AI also completely refactored my personal life. I make appointment notes with AI. I research stuff to buy with AI. I rarely use pure Google search. I vibe code apps for solving my daily issues like managing home finances or learning a new language. Fun times

Code generation

I’ve already mentioned this above, but code generation should have its own paragraph. I’ve never been a developer who loves to write code. I always enjoyed everything around it – analyzing customers’ needs, finding architectures that solve the issue, connecting different dots in the project, coordinating cross-team cooperation, maintaining the documentation or even writing tests. So code generation with AI is something I welcomed with open arms

As I’ve already mentioned, the vast majority of my code is AI-generated. I focus more on planning and reviewing it. It opens so many possibilities. I am also never hesitant or feeling blocked to start working on a task, because I always have a place to start – an AI agent.

AI Devs course

A huge step in my AI journey was taking and completing the AI Devs course. It’s been crazy 5 weeks of intensive learning about LLMs, AI agents and multimodality. Very practical, focused on solving real tasks. The course equipped me with solid foundations of the LLMs before the biggest shift with Claude Code and Opus 4.5 happened. It reminds me of diving into .NET internals years ago, just so today I can understand C# and the framework much better. It also opened my eyes to the possibilities LLMs give us. Things that were impossible (or very hard) to realize with pure code are now at our fingertips.

Attended non-technical tech conference

By the end of September 2025 I attended Beyond Code conference. It’s probably the only non-technical IT conference in Poland. The talks and discussions were focused around well-being, mindfulness at work, soft skills and psychology. Very needed type of events, especially in this crazy AI era.

Gave my first public talk

Another significant event was giving my first public talk at a local meetup in Bielsko-Biala. I presented my approach to working with AI tools and how we transformed the software development at the company I work for. The feedback I got was very positive and it was a very rewarding experience

I was invited to a podcast

Last but no least, as kind of an aftermath of the meetup talk, I was invited to an AI podcast episode. Przemek, who is one of the co-founders of Przeprogramowani (an initiative where the guys teach about AI development, basically), happened to attend my talk at the meetup and later invited me to record the podcast episode. We talked about AI again, this time in more depth. I also shared a little about digital nomad life. The episode got quite a lot of traction and positive feedback.

So… what’s next?

Ufff, I’m very happy that I got to this point. I really wanted to publish this article. I know it’s very personal, but that’s what I needed.

To be fully honest, I have no idea what to do with this blog. When I finally sit to it, I really like writing. This is by the way very common in my life recently – I commit to many projects that I really enjoy when actually working on them, but then I have no time to even start working on them, because they are too many

AI have completely reshaped the way I work and also changed my identity. I don’t anymore see myself as someone who will “help you becoming an independent full stack .NET web developer”, as the description in the sidebar of this page still says The free PDF I’m sharing as part of newsletter signup is completely out-of-date now. I don’t even know how I would need to reshape it to fit the current AI era

I don’t really know what’s next. Next for this blog, as well as for my activity in the IT community. Everything changes so fast… But maybe this is what we all found ourselves in right now? Maybe we just need to accept the current pace of things, outdated websites and blogs, as well as AI tools that become legacy a few days after being released?

The post Everything Has Changed appeared first on CodeJourney.net.

In this article, I’m sharing a compiled list of the most popular .NET interview questions I was asked during all those interviews. They represent real questions asked on job interviews for a software developer with almost 10 years of experience. Hope you enjoy it

Technical .NET Interview Questions

1. What’s the difference between a class and an interface?
2. What’s the difference between an abstract class and an interface?
3. What is the difference between a class and a struct?
4. Describe the difference between overriding and overloading in C#
5. Can a structure have virtual methods?
6. Explain the difference between GET, POST and PATCH in HTTP APIs
7. Is there any limit go the GET request’s length? If yes, where is such a limit configured? What about POST?
8. How would you secure your WebAPI?
9. What is the flow of generating, obtaining and passing JWT token in a .NET application?
10. When using JWT tokens in an API, how does the server ensure it talks to a legitimate client?
11. Is the API security compromised when the user’s JWT token is stolen?
12. What is the difference between IEnumerable and IQueryable in the context of Entity Framework?
13. What are the dependency injection scopes in ASP.NET?
14. How can dependency injection be helpful in testing?
15. What is IHttpClientFactory used for and which issues does it help to eliminate?
16. What is wrong with creating HttpClient manually?
17. What would you choose for implementing communication between microservices: REST or a message broker? What would you consider when making such a choice?
18. What would you do as a backend developer when frontend developers are blocked because they are missing an API endpoint from your side?
19. What is the size of stack in .NET?
20. What are value and reference types? What is the difference between them? Give a practical example
21. Which objects go on Large Object Heap?
22. What is JIT compilation?
23. Describe the strategies for delivering a message in a message queue
24. When is Dispose method called on a class implementing IDisposable?
25. What is the difference between Dispose and Finalize?
26. What is SOLID? Can you elaborate on each SOLID acronym?
27. You are assigned a task to process a large piece of text by inserting and changing many parts of it. Which of the following would you use for that task: string, StringBuilder, StringWriter or StringReader?
28. What’s the difference between Repository and Query Object patterns?
29. What is the Saga pattern?
30. What is CQRS and in which scenarios may it be beneficial?
31. What is the difference between an event and a command (like in CQRS)?
32. What are the advantages and disadvantages of using a Repository pattern?
33. What is Clean Architecture? Who invented it and how it works?
34. What is Onion Architecture?
35. What is Modular Monolith?

Experience-related .NET Interview Questions

36. Describe how you realized authentication & authorization in your last project
37. Explain your last project’s architecture
38. Explain a challenging task you faced in your last project and how you solved it
39. How would you approach diagnosing a performance issue on production, which cannot be reproduced locally?
40. Explain the “event-based architecture” you implemented in your last project. This was something I explicitly mentioned in my resume, so the advice is: prepare to elaborate on every experience you mention in your resume
41. How would you choose tech stack for a new full stack web application (backend + frontend)? Describe your decision-making process: what would you take into consideration when choosing a tech stack?
42. How would you decide whether to use an already-existing component (e.g. a library) vs implementing your own?

Final tips

These were not all of the questions I was asked, but the ones that recurred most frequently. As a programmer with almost 10 years of professional experience, I wasn’t asked many basic programming questions. The recruiters were mostly focused on my experience. They wanted to know how I solved problems at work in the past and what’s my approach to tackling issues. Rather than asking me theories about a design pattern, they wanted to know how I applied it in practice and whether I was happy with deciding to use it in the first place.

My general advice is to be patient and iterate. After each technical interview, try to write down as many questions as you can remember. This will help you be better and better prepared with each interview you take. Don’t forget to update your LinkedIn profile and keep building a quality network, even if you’re not on the job lookout right now. It comes in handy!

If you happen to be in a work search right now, I keep my fingers crossed! I hope these .NET interview questions will help you get that dream job

If you’re interested in knowing something about programming job search in current market conditions, feel free to leave a comment

The post Real .NET Interview Questions (2024/2025) appeared first on CodeJourney.net.

The answer to all these questions is mutation testing. Interested? Read on

Code Coverage – Our Old Friend

You probably know what code coverage is. Traditionally, many teams tend to measure how good their tests’ suite is by percentage line / statements / functions coverage. Some even require this metric to be 100%. Let’s start with this well-known approach first.

We are working with TicketsPriceCalculator class today. It contains some simple business logic:

As you can see, the class has one function whith returns the total price to be paid for a set of tickets. On the way, it applies various discounts based on some business rules. Fair enough.

It’s a critical piece of business logic for the app we’re working on, but it has never had any tests. We were asked to write unit tests for this class. Our manager strictly requires the code coverage to be 100%. Let’s do it then. We will go line by line, analyze the business logic and add the tests. Below, you can see the results of running those tests (you can find the tests code here):

Wow, that’s awesome! We did a great job. We have 8 unit tests which provide 100% statements, branch, functions and lines coverage!

So now we are really safe, aren’t we?

Yeah… until you know what mutation testing is

What Is Mutation Testing?

The idea of mutation testing is to mutate (change) our code. Mutation testing tools introduce changes into our production code. These changes can be really anything – from reverting a condition of an if statement, to changing some operators or changing a string value. For instance, here are some logical mutations Stryker Mutator is able to introduce (you can find the list of all mutations supported by Stryker here):

In effect, they generate modified versions of our code, which are called mutants. Makes sense

Each mutant contains a single modification in our source code. What happens next is crucial. Mutation testing tool takes this mutant (it is used as the code under tests now) and executes all of our unit tests against it. The result may be twofold:

• all tests have passed. In other words, the mutant has survived. This is a bad situation. It implies that the modification of our source code was not detected by our tests
• at least one test has failed. In other words, the mutant has been killed. This is a good scenario. It means that our tests detect changes in the production code and efficiently cover this particular scenario.

The flow is more or less like this schema from Peter Evans’ blog presents:

But why would anyone change the production code on purpose by introducing some stupid changes? It may seem counterintuitive for now, but let’s see how we can use it to our leverage.

Mutation Testing with Stryker Mutator

Let’s clearly state what we are starting with:

8 unit tests, 100% code coverage

Let’s now run mutation testing on our code. We are using TypeScript here, so let’s go with Stryker Mutator.

Here’s the result of running Stryker with npx stryker run on our code:

As you can see, 53 mutants were killed, but 15 of them survived. This gives us a mutation score of 78%. Let’s call it mutation coverage from now on. So to make it clear, this is our starting situation:

8 unit tests, 100% code coverage, 78% mutation coverage

Let’s now see how to kill those remaining mutants.

Killing First Mutants

In order to kill the mutants and improve our mutation score, we need to write more unit tests. Sounds logical, doesn’t it?

If still not, let’s take a deeper look at mutation tests results in VS Code. Stryker lists details of every survived mutant, for example this one:

Stryker changed the greater or equal (>=) operator to greater operator (>). This is a very common and very useful mutation. It usually means that our tests don’t cover the edge case associated with this particular condition.

In this case, the edge case value seems to be 5. More precisely, what happens if the number of business class tickets is exactly 5? We don’t know, because there is no test for this particular edge case!

Let’s add it:

The test passes. Let’s run mutation tests again:

That’s it! We have a new unit test and 1 more mutant killed Current state:

9 (+1) unit tests, 100% code coverage, 79% mutation coverage

I think you’re now getting what this is all about. We should be adding unit tests to cover the edge cases detected by mutations until all (or most) mutants are killed.

Mutation Testing – Free Unit Tests Generator

After adding 1 more test, the results look as follows:

10 (+2) unit tests, 100% code coverage, 86% mutation coverage

Finally, this is what we managed to get after a few minutes of work:

And we now have 17 unit tests in our suite! The final score looks like that:

17 (+9) unit tests, 100% code coverage, 96% mutation coverage

Notice what happened here. We started with 8 unit tests and finished with 17! This is awesome! That’s how mutation testing is a free unit tests generator. And you don’t even need AI for that

What’s more, the generated mutations even forced me to make a little tweak to the production code. It exposed some things that didn’t make sense. I could make this change to the production code, because my tests’ suite was already quite substantial.

Note that I didn’t push to gain 100% mutation coverage. The 3 mutants that survived don’t make much sense in our case. I encourage you to get the code and execute npx stryker run in the application folder to see for yourself

The percentage value doesn’t matter in that case. What matters is that we got 9 new unit tests and our tests’ suite is more robust. Now we can go and tell our manager that the business-critical code is well tested

So What Now?

I hope you see how valuable mutation testing is. It’s not a perfect tool that suits all cases. For example, it’s not easy to use mutation testing for complex legacy code. However, if your logic is nicely isolated, it could be a great tool. Especially if your production code heavily depends on calculations and many conditions. You may be surprised how many edge cases mutation testing can find.

I also love using mutation testing with TDD. These two techniques nicely complement each other.

I encourage you to go and try mutation testing. There are different mutation tools for various programming languages:

• C#, JavaScript, TypeScript, Scala: Stryker Mutator
• Ruby: mutant
• Java: pitest
• PHP: Infection
• C++: Mutate++

…and probably many more. Just do some research for the language you work with and give it a try Because testing is cool, isn’t it?

You can find the full source code used in this article here.

The post What is Mutation Testing and Why Should You Use It? appeared first on CodeJourney.net.

I’ve been trying to figure out how to make the most of this time. Since I’m a bit stuck in kicking off this new ‘project,’ I thought I’d write down my thoughts and struggles.

If you’re curious about how I’m planning to use these two months without paid work to improve my programming skills (and why I can’t seem to get my productivity back), read on

Background

For context, here’s a little background about myself:

• 9 years of programming experience.
• I consider myself a full stack web developer (.NET + React).
• I’ve worked the longest with .NET and C# (9 years), but I feel most confident with React and TypeScript (5 years of experience).
• I love talking to end users, product owners, and “business people.” Discussing ideas, finding weak points, and proposing solutions feels like being a kid in a candy store to me
• I once led a team of up to 10 programmers but decided to return to hands-on programming, and I love it.
• My weakest point as a programmer at the moment is UI/UX design. I can create a nice responsive UI with CSS, but it always takes more time than I’d like. I started learning Figma but haven’t yet designed a real app with it.

By the end of February 2024, I quit my job and went on a few-months-long holiday.

After 5 months of travelling in SE Asia and Oceania, I decided it’s enough. Then I realised I had a rare opportunity: two months entirely dedicated to self-development, with no immediate need to earn money. This article is my attempt to navigate this exciting yet daunting time.

That’s more or less it about my background Let’s now move on to what I want to achieve.

Project Goals

As I mentioned, I have around 2 months to dedicate to something full-time, without the pressure of getting paid. I’m calling it a project, even though I haven’t defined exactly what it will be.

My current goals for this self development project are:

1. Build or create something I can showcase in my portfolio. So far, most of my work has been on commercial, closed-source projects, so there’s nothing concrete I can show as a result of my work.
   
2. Prepare myself to return to work in 2–3 months on better terms. This means securing a position with flexible or undefined hours, very few or no meetings, and working on interesting projects (fully remote, of course). This might be working on my own projects or providing services.

As you can see, none of the goals are financial. This means that whatever I do or create doesn’t need to make money right now—no pressure for fit-to-market ideas.

None of the goals are purely technical, either. This is both good and bad, as it’s the root of one of my current struggles: choosing what to actually do We’ll dive into those excuses soon.

I also have a lot of free time for the next 2 months. I’m even treating this as a full-time project (up to 8 hours a day). On the other hand, 2 months is not a lot of time for creating, for instance, an application from scratch.

Ideas

I have several ideas on how to use (or not waste? ) this time. Let me just list them here:

1. Develop a mobile task and life management app. I’ve been using Nozbe for years (and even recommended it to everyone), but the team behind it recently stopped developing the app (they switched to a version for teams, which I don’t like) and also increased prices. I don’t find the app worth it anymore. I have specific needs for a task management app (like custom masks and computations based on them), so it could be a useful product for me. However, task management apps are so cliché… Anyway, there are unique ideas in my mind to make this app different from others and to make the process more fun. It would need to be a mobile app, since a smartphone is where I need it the most.
2. Develop a mobile app for specialty coffee enthusiasts. It could help with tracking different types of beans, brewing methods, preparation conditions, and the taste of the coffee. Sounds like a cool app I’d use myself. Again, mobile-first is a must here.
3. Contribute to some open-source projects. This should be quicker and easier to start. It’s also a nice way to show my activity on GitHub to potential future clients. Open-source contributions could lead to new connections and possibilities.
4. Spend this time learning programming skills I feel I’m missing or not very good at. See: UI/UX, Next.js, authentication in .NET, etc. However, such “to-learn” lists are infinite (I guess you also have one ), and this involves mostly passive learning (watching courses, YouTube, reading blog posts). It’s hard to make it a practical experience, and there wouldn’t be much to add to the portfolio afterwards.
5. Generally: build an app in public. Take one of the app ideas and build it in public. For instance, publish an update every day on Twitter and weekly on the blog. Or maybe share my progress on YouTube? This could work great or be disastrous and kill the project on day 1.

I had many more ideas, but I think it doesn’t matter much at this stage. These are just ideas. The only thing that matters now is the execution. But, of course, there are hundreds of blockers… eghm, excuses

My Doubts and Struggles (Also Known as Excuses)

This is the therapeutic moment of writing this article. I want to lay out everything that’s blocking me right here, right now, on paper—all the excuses, all the reasons I procrastinate and write this article instead of getting things done I’ll shed a bit more light on each of them below.

Excuse 1: Leverage My Existing Skills or Learn New Ones?

Should I leverage my existing skills (.NET + React) and build using only those, or should I dive into a new technology like React Native? Does it even matter? Is the choice of a tech stack more important than the idea (goal, final product) itself? I’m a software engineer; technology is just a tool in my toolbox. But that doesn’t change the fact that a new framework or tool must be learned. Do I want to learn it now, on the go? Do I need it? What will learning React Native give me at this point? Do I want to become a mobile app developer? Will developing one app make me a mobile app developer?

If my ideas are mobile-first, is using .NET and React enough (I can always make it a PWA), or do I need a native approach (React Native, again)?

While the choice of technology is a major decision, it’s not the only thing on my mind.

Excuse 2: What to Do?

Which idea should I pursue? Are 2 months enough to build something I can showcase to future clients? Maybe contributing to open-source projects is a better idea than creating a product from scratch?

But… should I think about money here?

Excuse 3: Build for Fun or for Money?

Everywhere I look, people are building their SaaS applications. “Find the perfect market fit,” they say. “Don’t waste time building something no one will buy. Validate your idea before writing a single line of code.”

I get that. But I don’t want to do anything like that right now. I want to have some fun and learn something new. However, I still hear those little whispers in my head: maybe think of a “real” product idea… Do more market research… Find the perfect idea… They’re telling me to use my time wisely, not just for fun. But hey, who wouldn’t want to have fun for 2 months?!

Excuse 4: How to Actually Start Creating?

I watched a fantastic React Native crash course (which is what I love to do when diving into new technologies). I was motivated to start working on Quiker (codename for my todo-life-everything-management app).

And then it hit me. How do I actually start this app? I need a design. But I don’t have one. Ok, let’s start simple with the login and register screens. But I still need a design. Should I learn Figma now? Should I design with StyleSheet or learn NativeWind (it looked so neat in the tutorial)?

I guess it’s going to be like that with anything I choose to do… So why not write an article instead?

Excuse 5: I Prefer Writing About Doing to Actually Doing

As you may have already noticed, I prefer writing about stuff to actually doing it I’ve always been like that. I love sharing knowledge, writing, and publishing. My tendency to put everything down in writing has been with me for years. Maybe it’s actually an advantage? I need to think how to leverage that.

But there must be some boundaries here. Nevertheless, I decided to write this article after a few days of no progress on the project itself. We’ll see if it helps with the actual doing.

Excuse 6: Should I Build in Public?

My secret dream is to be a YouTuber. I actually started 15 years ago – pretty badly, but still

I’ve been thinking about building an app in public. Sharing all my struggles and excuses (have I already started?). Showing how I’m learning and approaching the creation of something from scratch. Weekly updates on YouTube sound very appealing, but I’ve never done that for programming.

Building in public could have great benefits, like increased motivation and the accountability of a public declaration. On the other hand, it might kill the project if I put too much pressure on myself and stumble along the way. Especially if I… fail.

Excuse 7: What if I Fail?

What if I start building and don’t deliver? Even worse, what if I start building in public and don’t keep my promise? I know rationally that I’ll learn something along the way, but The Chimp still keeps saying, “if you fail, you will be a failure”.

Summary

If anyone ever reaches this part of the article, I’m surprised (and honoured) I just wanted to get all my thoughts down on paper. At least I’ve clearly defined my current goals and discovered how many excuses I can come up with in 2 hours (the time it took to write this article)

What if I had taken these 2 hours to write some code instead? I wouldn’t have, anyway I simply needed this.

Have you ever faced similar dilemmas when starting a project? How did you overcome them? What would you work on if you had 2 entire months decidated to self-development as a programmer? I’d love to hear your thoughts in the comments!

The post What I’m Doing with Two Months of Full-Time Coding for Fun appeared first on CodeJourney.net.

In this short article, I will give you my 5 reasons why the backend code editor might not be the best IDE for frontend development

NOTE: calling this post a “rant” is obviously humorous This article is my own opinion, not a hate on anyone using different IDEs than I do.

1. Rider and Visual Studio are slow

While I consider Rider much faster than Visual Studio, even the JetBrains editor is too heavy for TypeScript development. Both of these apps are not good candidates for an IDE for TypeScript. They were designed to work with complex, backend solutions. These IDEs include a lot of features by default that can’t be turned off, most of which are not needed when working with frontend code.

This gets even worse if the solution you open contains both backend C# project and React app’s code, as it is in Visual Studio’s .NET+React template. With time, even loading such a solution takes a lot of time. Especially if you use Visual Studio with ReSharper

2. Less IntelliSense and tooling support

From my experience, Visual Studio doesn’t show as much IntelliSense info as, for instance, Visual Studio Code does. The navigation in TypeScript code doesn’t feel as smooth as it should.

When I tried to use Rider or Visual Studio as IDE for TypeScript, I had issues working with popular frontend tooling like Prettier and ESLint. Theoretically, there are plugins for both of these IDEs, but in my experience they don’t always work properly. For instance, the “Format on save” feature of Prettier often doesn’t work in Rider for me. ESLint makes Visual Studio even slower (is that even possible?! ).

It’s hard to fully explain if you only worked with TypeScript in Rider or Visual Studio, but I promise you that switching to VS Code makes a huge difference Read on to get to know why!

3. Confusion of concepts

Let me explain my approach to frontend and backend first. To me, as a full stack developer, working on a frontend app requires a different mindset than working on backend. For instance, developing a React app requires me to think The React Way (we discussed it already in an article about React state management).

In my view, editing both frontend and backend code in the same editor makes you confuse concepts. If you learned JavaScript/TypeScript after working with C# for some time, you probably experienced trying to use let in C# or declaring C# types with colon (:) But this is only a tip of the iceberg.

I think having a separate IDE for TypeScript makes you nicely switch context when working on the frontend app. Opening my TypeScript code editor, I immediately start thinking in frontend. It instantly switches my approach to writing code. I somehow start to behave like a frontend developer, not a full stack one.

I think such approach is beneficial. For instance, it lets me work on my frontend code as I would be a real consumer of the backend API, not the person who can implement the backend in whichever way I want. Thanks to that switching of viewpoint, I can focus on designing my frontend code properly, without worrying about the backend.

I also tend to make less assumptions like oh no worries, I will do it on the server. At that moment, with my IDE for TypeScript open, I am a frontend developer. It often leads to better API design later on, because I don’t make any assumptions about the backend. Working on a frontend part of the app, I usually use API mocks first, knowing only the shape of data that should come from the API. Only later, when I’m done with the frontend part, I switch to Rider to actually implement the API.

Of course, this can also work the other way around. You can first work on the backend, design your API according to the best practices (again – without even thinking about your frontend app) and finally switch to the frontend IDE, build the UI and consume the API instead of using mock in the first place.

I hope you got what I mean here, but it’s not easy to clearly explain

4. Temptation to sneak C# concepts to TS

This point is a consequence of the previous one. If your IDE for TypeScript is the same as your C# code editor, you will be tempted to sneak C# concepts into TypeScript. I often see .NET developers entering TypeScript world using var by default (which is kinda deprecated in JavaScript and considered a bad practice today) or enforcing C# brackets formatting style in their frontend code. I also noticed overuse of classes and inheritance in TypeScript, as well as confusing passing value/reference data directly into components instead of properly using state and props in React.

To sum it up: isolating yourself as a frontend developer by using a TypeScript-specific IDE (like VS Code) will help you learn good frontend practices quicker

5. Because VS Code is better

Last, but not least: the main reason to not use Visual Studio or Rider for TypeScript development is simple: Visual Studio Code is better!

VS Code is industry standard for frontend development today. According to Stack Overflow Developer Survey 2023, over 70% of all developers use Visual Studio Code:

VS Code is lightweight. It doesn’t have all heavy features included by default. If you want something additional, it must be installed as an extension. By the way, the extensions are really great and actively developed by the community.

VS Code is mostly written in TypeScript, which makes is somewhat designed for TypeScript. It has great search features, awesome IntelliSense for TypeScript and works really fast. Especially compared to Visual Studio or even Rider.

Visual Studio Code can also be run on any platform. It even has a fully-featured web version. The IDE is also completely free and open-source.

I think I won’t continue listing numerous advantages of VS Code here. If you’re reading this, and you are still not encouraged to switch to VS Code for TypeScript development, please give it a try Or another try if you already tried, but it didn’t click. This time, first watch some introductory videos with tips on how to get started and get the most of the editor. You can also check the VS Code extensions I use on a daily basis to make your work with this editor easier.

Summary

That’s it! I really wanted to write this article one day. Do you know that feeling when you learned something new or made significant progress in some area of your life, and you see people still struggling with what you have overcome? It’s this moment when you would really love to give these people all of your knowledge and make them magically change their lives – the same way you did I feel exactly that when I see fellow developers struggling (it’s a matter of opinion, I know ) with Typescript in Visual Studio

I know I can’t change you and your beliefs and I don’t want to do that. But the great thing is that I can share my point of view and try to encourage you to alter yours a little. At least try and let me know what are your thoughts on that

Also, if you’re a frontend or full stack developer working in a backend IDE like Rider or Visual Studio, let me know why! I’m really curious. Did you try VS Code? If yes, what didn’t fit?

The post 5 Reasons To Not Use C# IDE For TypeScript Development appeared first on CodeJourney.net.

So what is React state management? How is it different from managing data in C# or Java? Let’s find out!

State

If you are a backend or desktop developer, you may have never come across the term of state. At least, I never used it before learning frontend web development. Surely not in the context it is used in frameworks like React. The term more familiar to me at that time was data binding known from WPF or WinForms.

This is what WPF documentation says:

Data binding is the process that establishes a connection between the app UI and the data it displays. If the binding has the correct settings and the data provides the proper notifications, when the data changes its value, the elements that are bound to the data reflect changes automatically

In case of WPF, the crucial part to me is If the binding has the correct settings and the data provides the proper notifications (…). If you have ever worked with WPF, you know how frustrating can these notifications be (any INotifyPropertyChanged fans here?).

WPF’s state management it not that bad. However, React has something better

React introduces us to a concept of state. In React components, you do not set anything directly, like calling some code to update an input’s value (this is possible, we’re still in JavaScript world, but it’s not a React way of doing stuff). You don’t directly bind your UI controls with data like you would in WPF or WinForms. Instead, you keep the data in memory, which is a current state of the UI (the whole app or a piece of it).

When the state changes, your UI is updated by React. In other words – in React, UI is a function of state:

UI = fn(state)

It means that your React app (or its individual pieces called components) take some state and output the actual, rendered UI.

This is React state management in a nutshell. Let’s explore it a bit more

Small disclaimer: I will focus on state in React functional componets. I consider class components somewhat legacy. I think this meme summarizes it best :

The Naive Way

Let’s try to approach React state management as C# developer. In React, the basic piece of UI we create is a component. Let’s add one:

import Button from "react-bootstrap/Button";

export const NaiveComponent = () => {
  return (
    <>
      <div>I am a naive component</div>
      <Button variant="success">Click me!</Button>
    </>
  );
};

For now, we render some text and a button which does nothing. What we want is to have some data displayed, like a number, which is incremented on every button click. Let’s try to implement that naively:

export const NaiveComponent = () => {
  let myCount = 0;

  return (
    <>
      <div>I am a naive component</div>
      <div>Current count: {myCount}</div>
      <Button
        variant="success"
        onClick={() => {
          myCount＋＋;
        }}
      >
        Click me!
      </Button>
    </>
  );
};

Now, let’s check if it works:

It looks nothing happens To investigate that, we can add a console.log (the most common debugging technique in JavaScript world ) to the onClick event:

onClick={() => {
          myCount＋＋;
          console.log(myCount);
        }}

How does that look in the console now?

Woooow, something is really going wrong here! The data is updated in memory, but not reflected in the UI

Why does that happen? Because myCount is not a state. It’s just some variable we created hoping that it will work fine as part of the UI. Remember what we have discussed in the previous section – we need to start thinking in React. This is The React way, not Java way or C# way anymore.

The React Way

So, how to use React state management properly in our example? We need to make myCount be a part of component’s state. The simplest way to do that looks as follows:

export const TheReactWayComponent = () => {
  const [myCount, setMyCount] = useState(0);

  return (
    <>
      <div>I am a React Way component</div>
      <div>Current count: {myCount}</div>
      <Button
        variant="success"
        onClick={() => {
          setMyCount(myCount ＋ 1);
        }}
      >
        Click me!
      </Button>
    </>
  );
};

First, instead of declaring a “normal” variable for storing our UI-related data, we used the useState hook. As you can see, it returns an array with two things: our state variable (myCount) and a function to update its value (setMyCount). We also set the initial value to 0. A good practice is to always use a construct like [myCount, setMyCount] to destructure what useState returns into named, separate objects.

Now we are managing our component’s state The React Way. Does it work? Let’s see:

Great! We have just learned how the basic form of state management works in React. That was easy, wasn’t it?

Now, let us discuss one more aspect related to the state itself.

Reference vs value

We know the React Way for state management now. We feel confident. However, we are also used to how data is managed in C# or Java, especially in terms of handling reference and value types. This knowledge will come very handy now

Let’s try to create a bit more complex component:

type Person = {
  id: number;
  name: string;
  age: number;
};

export const ObjectHolderComponent = () => {
  const johnInitialValue: Person = {
    id: 1,
    name: "John Doe",
    age: 30,
  };

  const [john, setJohn] = useState<Person>(johnInitialValue);

  return (
    <>
      <div>ID: {john.id}</div>
      <div>Name: {john.name}</div>
      <div>Age: {john.age}</div>
      <Button
        variant="success"
        onClick={() => {
          const currentJohnObject = john;
          currentJohnObject.age = currentJohnObject.age ＋ 1;
          console.log(currentJohnObject);
          setJohn(currentJohnObject);
        }}
      >
        Make John older
      </Button>
    </>
  );
};

Now, instead of storing a single value in our component’s state, we store a whole object of type Person. The object has a few properties: id, name and age.

There is also a button. We want this button to take the current john object, increment the value of age on it and update the state. We do it The React Way using setJohn function returned by useState. Just to be sure, we also have the console.log(john) just before updating the state. Does that work as we expected?

Eh, what’s happening here this time? We can clearly see that age is updated on the object on each click, but why isn’t the UI re-rendered?

As I mentioned before, it’s critical to understand the difference between reference and value types here. If you don’t know it, go and make up for it now.

The reason it does not work is that we haven’t updated the actual content of john state variable by calling setJohn(currentJohnObject). What is really being hold in john variable is the reference (pointer, address in memory) to the actual object. And this is what React tracks. We didn’t really update it, because we assigned the same instance of the object to the state. It doesn’t matter that we updated its internal property age – the reference itself wasn’t updated.

How do we solve that? Well, in current solution we’d need to create a copy of john object before using setJohn to alter the state. In effect, we’ll get a new instance of the object in memory and john variable will hold a new reference (address) to it.

So, if we only change our onClick implementation to this one:

onClick={() => {
          const johnCopy = { ...john };
          johnCopy.age = john.age ＋ 1;
          setJohn(johnCopy);
        }}

Everything starts to work as expected:

I think you now understand how React state management works. I also hope that you see the issues managing state in such a way can bring. Even in this trivial example, we create a new instance of an object on every button click. Apart from memory usage considerations, this just looks ugly. Imagine manually creating copies of much more complex objects, like classes storing arrays or dictionaries. This gets pretty wild

We will see how this issue can be addressed by the end of this article. But first, let’s discuss props – another concept critical to really understand React state management.

Props

Apart from state, we also use props to control the state of our React components. The name is a short for properties, which quite well describes its purpose. Props are the data input provided to a component from outside (from a parent component). They are immutable and cannot be changed inside the component which receives them. Let’s see some examples.

Sharing state between components

The most common usage for props is sharing state between components. Imagine that you have an input, where the user manually enters some data. You want to use the current value of this input in two other components. This is where you need to share your component’s state (the value of the input) with these two other components. We often call it lifting the state up – you keep your state higher in the components tree, so the child components can use it.

Let’s try to see an example of connecting state with props:

export const PersonData = () => {
  const minimumAge = 5;
  const maximumAge = 100;
  const [age, setAge] = useState<number>(minimumAge);

  const handleAgeChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    const enteredAge = parseInt(event.target.value);
    if (enteredAge >= minimumAge && enteredAge <= maximumAge) {
      setAge(enteredAge);
    }
  };

  return (
    <>
      <Form>
        <Form.Group controlId="age">
          <Form.Label>Your age</Form.Label>
          <Form.Control
            type="number"
            value={age}
            onChange={handleAgeChange}
            min={minimumAge}
            max={maximumAge}
          />
        </Form.Group>
      </Form>
      <DaysLiving currentAge={age} />
      <YearsUntilCentenarian currentAge={age} />
    </>
  );
};

As you can see, at lines 4 and 9 we manage the state variable age. This is the old stuff we have already seen.

However, at lines 27 and 28 we are passing the age state variable into DaysLiving and YearsUntilCentenarian children components as currentAge prop. This is how the DaysLiving component is implemented:

type DaysLivingProps = {
  currentAge: number;
};

export const DaysLiving = (props: DaysLivingProps) => {
  const daysLived = props.currentAge * 365;

  return (
    <div>
      <p>You have lived for {daysLived} days.</p>
    </div>
  );
};

Notice that props is simply a typed object you pass to a function component. To make things easier, you can also use object destructuring and accept the props in the following way:

export const DaysLiving = ({currentAge}: DaysLivingProps) => {
  const daysLived = currentAge * 365;
  /// ... rest of the code

That way, you don’t need to write props.currentAge every time you want to use this property inside the component.

Does changing props always trigger a re-render?

Well, generally the answer to this question is yes. Every time a prop of a component changes, this component will get re-rendered. However, this is not entirely true

To make this belief true, we need to assume that this prop is changed in a React way. So, to take things literally, consider this component we saw before:

export const DaysLiving = ({currentAge}: DaysLivingProps) => {
  const daysLived = currentAge * 365;

  return (
    <div>
      <p>You have lived for {daysLived} days.</p>
    </div>
  );
};

From its perspective only, it accepts a currentAge property. For this component to re-render, it’s not enough that the currentAge property changes in any way. Its value must be changed by mutating the state in the parent component.

So, if the value provided as currentAge to DaysLiving component changes in the parent component by properly mutating the state (with setAge mutation callback, in our case):

export const PersonData = () => {
  // ...
  const [age, setAge] = useState<number>(minimumAge);

  const handleAgeChange = (event: React.ChangeEvent<HTMLInputElement>) => {
      // ...
      setAge(enteredAge);
    }
  };

  return (
    <>
      // ...
      <DaysLiving currentAge={age} />
      // ...
    </>
  );
};

the child component (DaysLiving) will get re-rendered.

This is because when a parent component changes, React by default re-renders the parent component itself and all of its children.

If you modified the age variable in the parent compont directly, without using setAge (which we already know it’s incorrect), the currentAge prop would technically change, but the DaysLiving component will not get re-rendered.

state vs props

This is a question that people oftern ask: what’s the difference between props and state in React?

I would start with addressing this differently: what do props and state have in common?

As you already know, both are used for React state management. Both of them influence when the components will be re-rendered by React. Props and state are the absolute foundations of React.

The main difference is that state is used internally in a component, while props are used to pass information from parent to children components. State is also naturally mutable within a component where it’s defined, but props are immutable and cannot be changed in a component that receives and uses them.

React state management libraries

That’s basically everything you need to know to be able to comfortably work with React state management. However, I mentioned before that managing state using only built-in React mechanisms actually sucks That’s why I’d like to make a short point on state management libraries.

Maybe you heard about Redux, Zustand or MobX. All of them are state management libraires for React. But why would you even need one? And should you learn one now?

In my opinion, you can easily start working with React using the built-in state management mechanisms we discussed today. It’s good to know how it works in practice. However, the truth is that as your application grows and you want to keep it scalable and maintenable, you will need a state management library at some point. As soon as your components tree gets bigger, sharing data and state will not be as easy as “passing props to a children component”. You will need to share state between multiple components in the tree, sometimes not only between parent and children, but also with another components defined on the same level or even in a totally different place of the tree.

This is where React state management libraries come very handy. They solve many of the React’s issues that come to the surface as your state gets complex. But even if you use one, you will still always need state and props. That’s why it’s critical to understand these two basic concepts first and play with them for some time.

If you’re starting out, it’s good to know that state management libraries exist and that one day you will have to get your hands on one (or more ) of them. I hope to share my thoughts on state management libraries in a separate article one day.

Summary

That’s it! Now you should know how React manages state of its components. Of course, we didn’t cover everything related to state management in React, but I hope you got the basics

You can find all of the source code used in this article here.

How do you manage state in your React apps? Do you use a state management library? If yes, which one and why? Let me know in the comments below!

The post React State Management Basics appeared first on CodeJourney.net.

In this article, I will explain TypeScript compiler to you in simple terms. We will avoid complex stuff – only what you need for your everyday frontend developer’s work. We will not explore the inner workings of the TypeScript compiler Instead, we’ll see some practical implications of its workings for TypeScript developer. Let’s dive in

Few basic facts about TypeScript

For starters, let’s establish some quick facts about TypeScript as a language.

TypeScript is a superset of JavaScript

You may have heard that TypeScript is a superset of JavaScript. In other words, every JavaScript code is a valid TypeScript code. In case of TypeScript, being a “superset” means adding types information on top of perfectly legit JavaScript code.

Why is TypeScript only adding its types on top of JavaScript? In order to be able to remove them easily But why would it do that?!

Browser doesn’t understand TypeScript

The answer is that TypeScript cannot be run directly by a web browser (or NodeJS).

Let’s take this trivial TypeScript code:

let age : number = 27;

and try to paste it into Google Chrome’s console in order to execute it:

As you can see, it fails. The number type annotation is unknown to the browser. It means that before any TypeScript code is run in the browser, the information about types must be stripped out. In the end, browsers and NodeJS environments can only execute JavaScript. This is in short what TypeScript compiler does, and we’ll get into the details soon. For now, this leads us to another conclusion, that…

TypeScript is for developers

As we have just discovered, types must be removed by the TypeScript compiler before the code can be executed by the browser. In fact, this line of TypeScript:

let age : number = 27;

produces the following JavaScript output when processed by the TypeScript compiler:

var age = 27;

This is effectively the same code we wrote in TypeScript, but without type annotations.

Wrong data types assignments will only be detected at compile time:

but as soon as it’s compiled, this protection is not there anymore

This discovery means that TypeScript is for developers. Its job is to make our lives easier. Of course, in the end it also improves the end users’ experience, because programming in TypeScript is much better than using pure JS. But you can already see that TypeScript it not present at runtime at all. It only protects us until the compilation step by static types checking.

The philosophy is more or less as follows :

What’s worth mentioning, as the language’s specification says, “TypeScript never changes the runtime behavior of JavaScript code”.

TypeScript compiler in practice

tsc

TypeScript compiler is actually a CLI tool called tsc. It can be installed globally on your machine and used directly or built into your IDE. Refer to official documentation for installation details.

The compiler can also be installed locally in your project. It can then be set up as part of the build pipeline, which is supported by many bundlers. That’s why, when working on a TypeScript project, you may never encounter any direct usages of the tsc command.

tsconfig.json

In order to make working with TypeScript compiler easier, you should use a tsconfig.json file. It’s a JSON file containing all compilation settings. This is quite important, because, in opposite to C# or Java compilers, the TypeScript’s one allows for quite extensive (and flexible) configuration.

When you use the tsc command, it looks for tsconfig.json file in the current directory or any of the parent directories until it finds one. You can also provide a custom tsconfig.json location via --project parameter.

The simplest tsconfig.json file you get after initializing a new TypeScript project with tsc --init looks as follows:

{
  "compilerOptions": {
    "target": "es2016",
    "module": "commonjs",
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true
  }
}

We will not explore all the individual settings in this article. The official documentation does a great job.

TypeScript compiler – example

Let’s now see how it works.

Having a bit more complex TypeScript file as an example:

class Person {
  private name: string;
  private age: number;

  constructor(name: string, age: number) {
    this.name = name;
    this.age = age;
  }

  public getName(): string {
    return this.name;
  }

  public getAge(): number {
    return this.age;
  }
}

const person = new Person("John", 27);
console.log(person.getName()); // Output: John
console.log(person.getAge()); // Output: 27

Notice the .ts extension. This tells the compiler that this file contains TypeScript code.

Having tsc installed globally, we can compile it by executing the following command:

tsc test.ts

For the file given above, the output of this command is the following JavaScript file:

var Person = /** @class */ (function () {
  function Person(name, age) {
    this.name = name;
    this.age = age;
  }
  Person.prototype.getName = function () {
    return this.name;
  };
  Person.prototype.getAge = function () {
    return this.age;
  };
  return Person;
})();
var person = new Person("John", 27);
console.log(person.getName()); // Output: John
console.log(person.getAge()); // Output: 27

Few things to note:

• there is no information about types in the .js file. As we discussed before, this is intentional – only pure JavaScript code can be understood by the browser
• notice there is no class keyword used in the compiled JS code, even though classes were introduced in ES2015. This is one of TypeScript compiler’s features – to produce code which is supported in most of the browsers and JS engines, without having to wait for support of new JavaScript versions
• comments are left untouched

This explains how the TypeScript compiler works. It also confirms what we stated before, that TypeScript is for programmers. As soon as your code is deployed to production, the types you added in .ts files are absent. The way this process is built gives a lot of advantages, but it may also be a source of confusion – let’s see how exactly.

TypeScript compilation flaws

Finally, knowing how TS -> JS compilation works, let’s quickly explore some of its common flaws.

No runtime protection

As you now know, TypeScript stripes out the types during compilation. It means that the information about types is not present at runtime (when our code executes). Because of that, we are not protected by TypeScript at runtime. Consequently, if an input comes from a user and the inputs themselves are not well validated, we may still get runtime type errors. Imagine that your code expects a number, but the user enters a string because of lack of proper input validation. TypeScript will not protect you here.

The same applies to validating API responses. Most data from HTTP APIs comes in a form of JSON. In TypeScript, we can represent such data as type or interface. Based on those expected shapes of data, we use objects of a given type and assume that given properties are present on them or not. However, APIs may change, and TypeScript will again not protect us at runtime. We still need to resort to alternative solutions for runtime types validation.

To be completely clear – I don’t think that no runtime protection is something TypeScript lacks. On the contrary – I love the flexibility of TypeScript which this approach gives. It’s just how the language has been designed, and we should be aware of that

Debugging complexity

When working on a TypeScript project, the code you see on production is different from the one in your IDE. Sometimes not only types are stripped out by TypeScript compiler, but as you saw earlier it may also convert some constructs to the other (like changing a class to a function). It makes debugging, especially directly on production, more complex.

In order to place breakpoints and actually have them hit in your TypeScript code, you need source maps. It does the job in most cases, but adds to the complexity at the same time, not always working seamlessly.

TypeScript is sometimes too strict

If you decide to migrate your JS project to TypeScript, you will quickly get frustrated by how strict this new language can be. Especially if you are coming from JavaScript world where everything is allowed

There are countless memes about that, but here is the one I like:

Joking apart, most things TypeScript complaints about can be configured/turned off in tsconfig.json file. This is actually what I like about TypeScript. It brings static typing into JavaScript world, but lets you control how strict you want it to be. So, if you get frustrated with TypeScript compiler’s complaints, remember about configuration options

Summary

I hope that now you feel more comfortable working with TypeScript compiler

If you’re a .NET developer, and you enjoyed this article, I think you may also find my free guide useful:

The post TypeScript Compiler Explained appeared first on CodeJourney.net.

If you’re starting your web development journey, or maybe have already dived into it, but are not really sure what JS bundlers are and what’s their role, you’re reading a proper piece of explanation

Chaos and complexity – the issues

Let’s consider a very simple JavaScript app. We have just one page index.html. Our HTML is hydrated with index.js file, which adds some interactivity to it. In order to use it, we need to import index.js script in index.html file. We also decided to use an external library (Bootstrap), so we should also link the necessary CSS.

We are linking the index.js with a script tag in head section:

<head>
    <script type="module" src="index.js"></script>
    <link
      href="https://cdn.jsdelivr.net/npm/bootstrap@5.2.3/dist/css/bootstrap.min.css"
      rel="stylesheet"
      integrity="sha384-rbsA2VBKQhggwzxH7pPCaAqO46MgnOM80zW1RWuH61DGLwZJEdK2Kadq2F9CUG65"
      crossorigin="anonymous"
    />
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>My WebPage</title>
  </head>

Of course, as we are building a web application, we won’t put all the JavaScript code in index.js. That’s why we created two separate files with some functionalities: my-utils.js and navigation.js.

For instance, the my-utils.js exports a few functions:

export function doSomethingNice() {
  alert("Nice!");
}

export function notUsedFunctionA() {
  alert("Not used function A");
}

export function notUsedFunctionB() {
  alert("Not used function B");
}

export function notUsedFunctionC() {
  alert("Not used function C");
}

Notice the not used functions there – we’ll get to the point of them soon.

Next, our index.js file imports what it needs and adds some interactivity to the HTML elements:

import { doSomethingNice } from "./my-utils.js";
import { reloadThePage } from "./navigation.js";

document
  .getElementById("reload-page-btn")
  .addEventListener("click", reloadThePage);

document
  .getElementById("say-sth-nice-btn")
  .addEventListener("click", doSomethingNice);

If we now open our webpage, we can see the network activity when the page is loaded:

Notice that all 3 JavaScript files are fetched separately: index.js, my-utils.js and navigation.js.

What’s more, if you check the contents of my-utils.js, it obviously loads the whole script, containing even the not used functions:

I think you might already feel that this can get a little problematic Imagine managing this when you have hundreds of your own JavaScript files plus dozens of external libraries. Not only will your app be making hundreds of network requests to fetch every single file, but it will always fetch everything – even the stuff your page doesn’t use.

Here’s where a JavaScript bundler comes into the field.

You can find full source code of this JavaScript app here.

What does a JavaScript bundler do?

JavaScript bundler produces bundles But what is a bundle? It’s basically a static file, optimized to be served to the client (in our case: a web browser). The main goal is to produce a single bundle file from multiple dependencies. In effect, the user’s browser doesn’t need to fetch so many files separately. But how is such a bundle created?

First, a JavaScript bundler needs to know the entry point. It’s a kind of root in which our “code tree” begins. In the case of our sample JavaScript application from the previous paragraph, a perfect candidate for an entry point would be the index.js file. Modern bundlers support multiple entry points. It can be very useful if you’re building a multipage application, so each page can have its own entry point.

The next step is to create a dependency graph. The JavaScript bundler is basically starting from the root (entry point) and traverses all dependencies referenced from it, as well as all of these dependencies’ dependencies. Having the dependency graph, bundler knows what is exactly used by what and in which place of our app.

This is how you can imagine the graph of dependencies:

Module bundlers like webpack not only know the dependencies of your entry point. These tools even check what each dependency uses. Thanks to building such a detailed dependency graph, the bundler can introduce multiple optimizations into the bundle file.

Finally, JavaScript bundler outputs the actual bundles. As I mentioned, bundles can be highly optimized by applying techniques like code splitting, CSS inlining, HMR and various performance optimizations.

JavaScript bundler might also ensure the backwards-compatibility with older web browsers by converting some newer JavaScript constructs used in your code to their equivalents from previous JS versions.

What’s interesting, modern bundlers can handle not only JS files, but also CSS, HTML and even images.

JavaScript bundler in action

Currently, the most popular JavaScript bundles is (still) webpack. It has been the first really advanced bundler created for both the browser and NodeJS.

You might have heard unpleasant things about webpack and in fact, its configuration can get really spaghetti There are simpler alternatives out there, but let’s start with what’s the most common tool used in web development today.

Adding webpack to a JavaScript app

Our sample app already has a package.json file (we used JavaScript modules), so we can install webpack with this command:

npm install --save-dev webpack webpack-cli

Now we should reorganize the files a bit. Let’s put all scripts in src folder and move index.html to dist folder. Finally, it looks like that:

Using the folder named dist is very common. It stands for distributable, which means the code ready to be distributed = served to the public. This is where our bundles will be located. As the index.html is directly served to the public, we also place it there.

With such a folders structure, there’s nothing more we need to configure for webpack to work. By default, webpack looks for src/index.js file which we already have and outputs bundles into the dist folder. To use more advanced features or multiple entry points, a configuration file should be added.

In our case, let’s go with the zero-config approach. The only thing we need is to add a script entry to package.json:

  "scripts": {
    "build": "webpack",
    "test": "echo \"Error: no test specified\" && exit 1"
  },

Let’s now run npm run build and see what happens:

It seems that webpack created the main.js asset (bundle):

Let’s make sure that our index.html page links this bundle file properly:

<!DOCTYPE html>
<html lang="en">
  <head>
    <script type="module" src="main.js"></script>

Now, let’s open our index.html page and see how the network requests look like now:

Wow, that’s something different from what we had previously! Notice that now only 1 script, the main.js file, is fetched by the webpage. There were 3 before: index.js, my-utils.js and navigation.js. Of course, the web page works exactly as before.

Let us also examine the contents of the fetched main.js file:

Pay attention what happened here. Webpack has nicely inlined all the external code we used directly into the main.js bundle. What’s more, the exported, but not used functions from my-utils.js are not present here at all! When building the dependency graph, webpack noticed that those functions are not used, so it didn’t include them

This is basically how webpack and most JavaScript bundlers work. Their role is to deliver the smallest and the most optimized bundles possible. This ultimately saves a lot of bandwidth by avoiding unnecessary network requests the client browser would otherwise need to make. Cutting out the unused code makes the bundles smaller, again reducing the network usage.

You can find full source code of the webpack app here.

Webpack has a lot more to offer

From all the JavaScript bundlers used today, webpack is the most advanced one. It’s the most mature one as well. It offers dozens of customizations, plugins and loaders. You can also easily add TypeScript support.

You can do really crazy stuff with webpack However, if you are starting your web development journey, don’t get overwhelmed by learning it all. Just be aware that webpack can do almost everything you might need. It’s just a matter of searching StackOverflow or asking Copilot

Alternatives to webpack

In recent years, developers created a few other amazing JavaScript bundlers. I recommend you to pay attention to them, because webpack doesn’t have to be your first choice today. Webpack is still used in CRA, which is believed to be a default way of creating new React applications. This is what makes it very widely used, but you don’t need to follow this path

I recommend checking Parcel, esbuild and ViteJS. These are modern bundlers created to, among others, eliminate some of webpack’s burdens. If you’re starting out and don’t want to get yourself busy with bundling configuration, I especially recommend creating your next app with Parcel.

Summary

That’s all that you need to know about JavaScript bundlers to be able to work with them and understand what’s happening when executing this magic npm run build script

If you’re a .NET developer, and you enjoyed this article, I think you may also find my free guide useful:

The post What Is A JavaScript Bundler? appeared first on CodeJourney.net.

Why?

You probably know what a wrapper is. As its name suggests, it’s a practice of putting another layer on a piece of something. In our case, wrapping a piece of code in another piece of code

But why would you do that? To make your life easier!
Wrapping external libraries lets you abstract your code from their implementation details. In effect, it makes your life a lot easier when you want to keep the behavior, but change the library providing it. This approach also lets you use only those features from a given external dependency that you actually need.
Let’s see that with an example.

Wrapping HTTP client

A very good example is HTTP client wrapper. HTTP calls are used in almost every web application. In order to perform them, we need to choose an HTTP client. We can either use fetch, or something more sophisticated like axios.

However, with time, we may decide to replace it with something else. There might be many reasons for that – either the library stops to be maintained or something new and better is out there. It would be a shame if we’d now need to change the code in those thousands of places where the current library is being used. This would take a lot of time and might be error-prone. We can definitely prepare better for such cases

Create HttpClient wrapper for axios

Let’s say that, for now, we will go with axios. Instead of calling it directly from our code:

import { useEffect, useState } from "react";
import axios from "axios";
import { Product } from "../types/product";
import { DummyJsonProductsResult } from "../types/dummyJsonProductsResult";

export const ProductsList = () => {
  const [products, setProducts] = useState<Product[] | null>(null);

  useEffect(() => {
    axios
      .get<DummyJsonProductsResult>("https://dummyjson.com/products")
      .then((result) => {
        setProducts(result.data.products);
      });
  }, []);
 
 // ...
};

I will create an HttpClient wrapper for it and use it instead.

First, I create httpClient.ts file in wrappers folder. I like to have such a catalog in my React projects and keep all the wrappers there.

I start writing all wrappers with an interface. In that case, I treat the interface as a contract. It should say what I need this small wrapper to do, without worrying about implementation details.

IHttpClient interface initially looks as follows:

interface IHttpClient {
  get<TResponse>(url: string): Promise<TResponse>;
}

That’s what we have so far. We just need to retrieve the data with GET method.

Next step is to create the actual implementation of IHttpClient using axios. This is pretty straightforward using a class implementing IHttpClient interface and taking a look at axios‘s documentation:

class AxiosHttpClient implements IHttpClient {
  private instance: AxiosInstance | null = null;

  private get axiosClient(): AxiosInstance {
    return this.instance ?? this.initAxiosClient();
  }

  private initAxiosClient() {
    return axios.create();
  }

  get<TResponse>(url: string): Promise<TResponse> {
    return new Promise<TResponse>((resolve, reject) => {
      this.axiosClient
        .get<TResponse, AxiosResponse<TResponse>>(url)
        .then((result) => {
          resolve(result.data);
        })
        .catch((error: Error | AxiosError) => {
          reject(error);
        });
    });
  }
}

This implementation lets us encapsulate a simple singleton inside the class.

The last step here is to expose the instance of our HTTP client. Remember to always export the interface type variable:

export const httpClient: IHttpClient = new AxiosHttpClient();

That’s basically how we wrap external libraries in TypeScript. Easy-peasy

Using the wrapper

I can now use our wrapper in ProductsList.tsx component:

import { useEffect, useState } from "react";
import { httpClient } from "../wrappers/httpClient"; // we don't import axios here anymore
import { Product } from "../types/product";
import { DummyJsonProductsResult } from "../types/dummyJsonProductsResult";

export const ProductsList = () => {
  const [products, setProducts] = useState<Product[] | null>(null);

  useEffect(() => {
    httpClient // instead of axios, we use our wrapper in components
      .get<DummyJsonProductsResult>("https://dummyjson.com/products")
      .then((result) => {
        setProducts(result.data.products);
      });
  }, []);
 
 // ...
};

Notice how easy that was. Since now, we only import stuff from axios package in httpClient.ts file. Only this single file is dependent on axios npm package. None of our components (and other project files) know about axios. Our IDE only knows that the wrapper is an object instance fulfilling IHttpClient contract:

Extra wrapper features

Apart from nicely isolating us from dependencies, wrappers have more advantages. One of them is a possibility to configure the library in a single place. In our example with axios – imagine that one day you want to add custom headers to each HTTP request. Having all API calls going via AxiosHttpClient, you can configure such things there, in a single place. That way, you follow the DRY principle and keep all the logic related to axios (or to any other external dependency) in a single place. It also comes with benefits like easy testability etc.

For clarity, I also added post support to our IHttpClient. You can check it here.

Replacing the wrapped library

Ok, it’s time to have our solution battle-tested. We have the HTTP client nicely wrapped and exposed as an instance of IHttpClient. However, we came to the conclusion that axios is not good enough, and we want to have it replaced with fetch.

Remember that in the real web application, you would have hundreds or thousands of usages of IHttpClient instance. That’s where the power of wrappers comes into play

So how do I make sure those thousands of usages will now use fetch instead of axios? That’s actually pretty straightforward. I’ll simply add a new class – FetchHttpClient implementing IHttpClient interface:

class FetchHttpClient implements IHttpClient {
  get<TResponse>(url: string): Promise<TResponse> {
    return new Promise<TResponse>((resolve, reject) => {
      fetch(url)
        .then((response) =>
          response
            .json()
            .then((responseJson) => {
              resolve(responseJson as TResponse);
            })
            .catch((error: Error) => {
              reject(`Response JSON parsing error: ${error}`);
            })
        )
        .catch((error: Error) => {
          reject(error);
        });
    });
  }

  post<TResponse>(url: string, data?: object): Promise<TResponse> {
    return new Promise<TResponse>((resolve, reject) => {
      fetch(url, {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
        },
        body: JSON.stringify(data),
      })
        .then((response) =>
          response
            .json()
            .then((responseJson) => {
              resolve(responseJson as TResponse);
            })
            .catch((error: Error) => {
              reject(`Response JSON parsing error: ${error}`);
            })
        )
        .catch((error: Error) => {
          reject(error);
        });
    });
  }
}

For completion, I included POST here as well.

The one last thing I have to do to make our new FetchHttpClient be used in the whole app in place of AxiosHttpClient is to change a single line with export:

export const httpClient: IHttpClient = new FetchHttpClient(); // instead of new AxiosHttpClient()

and that’s it! Our whole application now uses fetch for GET and POST HTTP requests And it even still works

Summary and source code

I hope that now you see how important it is to wrap external libraries. We have seen that on JavaScript/TypeScript app example, but this is applicable to any programming language and framework.

It’s always good to be as independent as possible of 3rd party stuff. Too many times I’ve been in a situation that some npm package is so extensively used in a project, directly in the source code in hundreds of places, that it cannot be replaced without spending several days on it. Creating wrappers forces us to think abstract, which is another great advantage.

You can find the complete source code here: https://github.com/dsibinski/codejourney/tree/main/wrapping-external-libraries

The post How (And Why?) To Wrap External Libraries? appeared first on CodeJourney.net.

After reading this article, you will know how to add such a menu to your React app. The end result will look as in the highlighted picture of this article

Creating a table with row selection support

First, let’s define a type of data that we want to display. For our example, we will display a list of Cars:

export type Car = {
  id: string;
  brand: string;
  model: string;
  productionYear: number;
  isAvailable: boolean;
};

Next, we create a new component called CarsTable, responsible for rendering the table. We will use @tanstack/react-table for the table behavior and react-bootstrap for UI elements.

I implemented the CarsTable component in quite a standard way according to react-table docs, so I won’t copy-paste it here. You can check the whole component’s code here. What’s interesting is that I added support for row selection in a way that makes our table a controlled React component:

type CarsTableProps = {
  selectedCar: Car | null;
  onCarSelected: (car: Car) => void;
};
export const CarsTable = (props: CarsTableProps) => {
  return (
    // ...
    <tbody>
        {table.getRowModel().rows.map((row) => {
          const isActive = row.original.id === props.selectedCar?.id;
          return (
            <tr
              key={row.id}
              style={isActive === true ? { backgroundColor: "#3a7a11" } : undefined}
              onClick={() => {
                props.onCarSelected(row.original);
              }}
            >
              {row.getVisibleCells().map((cell) => (
                <td key={cell.id}>
                  {flexRender(cell.column.columnDef.cell, cell.getContext())}
                </td>
              ))}
            </tr>
          );
        })}
      </tbody>
    // ...
  )
}

As you can see, selectedCar and onCarSelected are managed from outside. Line 14 shows how the row color gets changed for the currently selected car. I recently had to deal with such a case in one of my projects.

So far, so good. This is how it looks, populated with sample data:

Adding meatballs menu

Ok, we have a table. Now we want to add the meatballs menu. We need a three dots icon and a dropdown menu to open on clicking it.

After quickly going through the react-bootstrap docs, let’s create a new component for that:

import { Dropdown } from "react-bootstrap";
import { Car } from "../types/Car";
import CustomDivToggle from "./CustomDivToggle";
import { BsThreeDots } from "react-icons/bs";

export const CarRowContextMenu = ({ carRow }: { carRow: Car }) => {
  return (
    <Dropdown key={carRow.id}>
      <Dropdown.Toggle as={CustomDivToggle} style={{ cursor: "pointer" }}>
        <BsThreeDots />
      </Dropdown.Toggle>
      <Dropdown.Menu>
        <Dropdown.Item>Option 1</Dropdown.Item>
        <Dropdown.Item>Option 2</Dropdown.Item>
      </Dropdown.Menu>
    </Dropdown>
  );
};

As we want our dropdown toggle to have custom style, I had to provide CustomDivToggle as a custom dropdown component. It’s nothing very interesting, but you can check its implementation here

Next, as we’d like our meatballs menu to be an additional column in the grid, it seems natural to use react-table‘s display column. Let’s try adding it:

columnHelper.display({
      id: "context-menu",
      cell: (cellContext) => {
        const row = cellContext.row.original;
        return <CarRowContextMenu carRow={row} />;
      },
    }),

It looks we have it:

However, after clicking through it for a while, it seems we have an issue. The toggle only opens on every 2nd click:

Why is that? The reason is our controlled CarsTable component. On clicking a new row, the change event occurs, which triggers the re-render of the CarsTable component (because selectedCar actually changes). It makes react-table re-render the table, with the meatballs menu in its default state (collapsed). On clicking the menu in the same row again, the change event occurs, but the selectedCar does not actually change, which does not trigger the re-render. Initially, it took me a while to figure that out

Fixing double-click issue

In our case, a fix for the double click issue is quite simple. Instead of adding the column with the menu using columnHelper.display() function from react-table, we can render it manually. To do that, we should simply add a new <td> to each row of the table:

<tbody>
        {table.getRowModel().rows.map((row) => {
          const isActive = row.original.id === props.selectedCar?.id;
          return (
            <tr
              key={row.id}
              style={isActive === true ? { backgroundColor: "#3a7a11" } : undefined}
              onClick={() => {
                props.onCarSelected(row.original);
              }}
            >
              {row.getVisibleCells().map((cell) => (
                <td key={cell.id}>
                  {flexRender(cell.column.columnDef.cell, cell.getContext())}
                </td>
              ))}
              <td>
                <CarRowContextMenu carRow={row.original} />
              </td>
            </tr>
          );
        })}
</tbody>

Additionally, to make it work, we need an additional table’s header placeholder:

<thead>
        {table.getHeaderGroups().map((headerGroup) => (
          <tr key={headerGroup.id}>
            {headerGroup.headers.map((header) => (
              <th key={header.id}>
                {header.isPlaceholder
                  ? null
                  : flexRender(
                      header.column.columnDef.header,
                      header.getContext()
                    )}
              </th>
            ))}
            {/* placeholder header for context menu */}
            <th></th>
          </tr>
        ))}
</thead>

That’s it! Our `react-table` table with row selection support and the meatballs menu works like a charm now:

Meatballs menu with react-table – source code

You can find the complete source code here. I hope you find it useful!

The post Adding Meatballs Menu To React-Table Rows appeared first on CodeJourney.net.

Prettier

My number one. I was a bit skeptical initially, but today I can’t imagine my life without Prettier For those unfamiliar with the tool, Prettier is an opinionated code formatted. Opinionated, because it allows for almost no configuration. It reformats your code automatically based on its own rules.

It may sound scary and limiting, but it really frees your mind. Suddenly you forget about all those spaces vs tabs wars and discussions on which column shall the code be wrapped. Prettier does that all automatically. It can even be done on saving the file! Just take a look, how beautiful that is:

It is also very easy to execute prettier formatting with pre-commit git hook, so the checked-in code is always formatted, even if some team members don’t use it in their IDE.

Never again without Prettier!

ES7+ React/Redux/React-Native snippets

This is one of the first VS Code extensions I installed. It’s simple, yet very powerful! This plugin adds multiple JavaScript/React snippets. I create many new components every day. Snippets make it very easy:

I recommend trying this extension out and exploring its built-in snippets.

C# to TypeScript

This one is a time-saver for .NET developers working with TypeScript. It allows generating TypeScript interfaces from C# classes. You can simply copy a C# class and paste is as a TypeScript’s interface in Visual Studio Code:

You can also paste using keyboard shortcuts. There’s even a CLI tool available in case you’d want to automate this process. This extension doesn’t support all scenarios (especially no support for records ), but it still covers most simple copy-paste cases. By the way, synchronizing C# with TypeScript types is one of the challenges for full stack .NET developers.

Total TypeScript

From all VS Code extensions I use, this is the only one that actually helps me learn on the job. It was called TypeScript Error Translator before, and this is what I initially used it for. It basically provides more meaningful, crowdsourced translations for often enigmatic TypeScript errors:

When a translation is missing, you can always contribute one. Additionally, as its new name suggests, it also lets you learn programming concepts directly inside your code. As soon as it finds a new concept in the code, a brief explanation is shown:

It will stop highlighting this particular type of concept as soon as you mark it as learned. I think it’s a quite interesting way of learning on the job

ESLint

This is the extension for integrating the most well-known linter for JavaScript into Visual Studio Code. ESLint is a static analyzer of your source code which helps you find problems quickly. It will highlight issues in your code for all loaded files from your workspace. I don’t feel there’s much to write about here – just check their website and give this extension a try

Thunder Client

Thunder Client is like Postman, but built into VS Code. It lets you easily play with HTTP APIs. You can create your own collections of requests and export them to JSON, which can be checked into the source control.

Yet another very useful extension!

Preview.js

This is one of my recent discoveries. Preview.js allows to live-preview React, Solid or Vue components directly in VS Code. It also generates the initial props data, sometimes even for complex objects:

The plugin is also configurable for custom scenarios like external dependencies. You can find more information in the documentation.

WakaTime

If you like analytics, you should check this VS Code extension. WakaTime measures how much time you spend actually writing code. It shows exactly in which language you programmed for how much time. It also divides time entries into projects you worked on:

It’s interesting to get such insights “for free” and see how little time we spend actually coding Try it for yourself and let me know your results!

One Dark Pro

Who never started a new project by installing fancy tools, text editors or choosing the best color theme for your IDE? Of course – good colors = smooth -and pleasant – coding One Dark Pro is a must-have theme for my Visual Studio Code. I love it, it makes source code much more readable for me. What’s your favorite color theme for VS Code?

vscode-icons

Last but not least, a good friend to the One Dard Pro theme, legendary VS Code icons set. It has over 13M installs!

Apart from getting +100 to fanciness , it makes icons more explicit in the explorer:

As you can see, it even guesses the folder type based on its name – see types or utils folders’ icons above.

Not critical, yet helpful. Undeniably adds a million to your professionalism as a web developer

Summary

So, that’s it! The list of my 10 favorite Visual Studio Code extensions.

What about you? What are your must-have VS Code extensions?

The post 10 VS Code Extensions I Couldn’t Live Without appeared first on CodeJourney.net.

The symptoms of this issue are putting your mouse on something where you’d expect the IntelliSense guidelines, but instead you only see the “Loading…” text.

In this short article, I’m sharing the reason of this issue and my way of fixing it.

How VS Code Infinite IntelliSense Loading Looks Like

This is what I struggled with:

As you can see, I didn’t get any IntelliSense while hovering my mouse on various elements in the editor.

A similar thing happened when I tried to use Go to References (or Shift + F12 on Windows) for any object:

As you can see, the loading bar at the top of VS Code was showing progress infinitely.

Let’s now see how to fix this annoying issue

Fixing Visual Studio Code IntelliSense Loading Infinitely

After quite long investigation, I finally found the reason. It turned out that sometimes your Visual Studio Code might be using a different TypeScript version than your workspace uses. In my case, it was exactly the cause of the infinite loading problem

In order to fix it, use TypeScript: Select TypeScript Version... command. You can access commands with Ctrl + Shift + P on Windows or ⇧⌘P on Mac:

Select this command and tell Visual Studio Code to use the workspace version of TypeScript:

As you can see on the screenshot above, in my case the VS Code’s TypeScript version was 4.8.2, while the workspace version was 4.8.3. Changing it to use the newer, workspace version solved the problem. Visual Studio Code IntelliSense loading infinitely issue was gone

If it doesn’t work straightaway, you might need restarting your VS Code editor.

I hope that worked for you and saved you some hours of debugging and exploring StackOverflow

The post How To Fix Visual Studio Code IntelliSense Loading Infinitely appeared first on CodeJourney.net.

If you ever had an API action defined like that in your controller:

and fetched this data using TypeScript in the following way:

at some point, you probably also experienced the desynchronization of backend (C#, in our example) and frontend (TypeScript) types definitions. What if someone has changed the C# version of UserViewModel, but no one corrected its TypeScript’s equivalent?

Your TypeScript fetching code will tell nothing about that. There will be no error, even though the fetched data doesn’t match the expected UserViewModel type.

I’ll try to address this issue in this article Let’s see how typing API responses with zod can help us here.

Synchronization of Backend and Frontend API Typings

First, why would we want to keep the backend and frontend models in sync?

For me, that’s the purpose of using TypeScript. We want our code to be as well-typed as possible. For instance, we normally want the data displayed to the user to be fully typed. TypeScript enhances our programming experience by providing us with typing information. Thanks to that, we know what is what and what contains what. We also express what types of data we expect in particular cases.

The APIs mostly return JSON data, which can be anything. Because of that, it is much easier to have the data returned from the API fully typed in TypeScript. Thanks to that, we know what properties are available on the data models received from the API and whether we can use and display them to the users.

The sample code used within this article is available on GitHub. We will use ASP.NET Core (C#) and React (TypeScript) apps as examples.

Models synchronization example

As we saw in the beginning, a classic example is an API controller that returns a strongly-typed data:

The returned data type is a collection of UserViewModel objects. Here’s the C# definition of this type:

Its equivalent is also defined on TypeScript side:

Usage in TypeScript

Cool. With this simple code, we can create a usersService.ts file and fetch our users’ data from the API. Notice how we make this call strongly typed:

Everything looks legit. We can use the data retrieved from the API in UsersList component and everything is nicely typed:

The data is even perfectly displayed:

So, what can go wrong here?

The Problem – Typings’ Desynchronization

Let’s say that a backend developer implements a requirement to rename “loyalty points” into “fidelity points”. Easy. (S)he renames LoyaltyPoints property in the C#’s UserViewModel to FidelityPoints.

The new C# model looks as follows:

Nice! The backend dev is a very good programmer, so (s)he even launches the React web application to make sure that everything still works correctly and there are no errors in the dev console:

After a quick look, everything looks awesome. The users list is displayed, there are no errors in the console. Apparently, these test users don’t have any loyalty points assigned – that’s why the empty values in “Loyalty points” column. What’s more, translators will update the column’s translation later. We are good! Let’s go on prod!

I guess you already know what went wrong here. API definition changed, but TypeScript didn’t inform us about that Our UserViewModel still uses the old property name:

However, it still works. When rendering the UsersList, we simply get undefined in place of loyaltyPoints:

In the end, this is all JavaScript there. What’s interesting, the renamed fidelityPoints property is already there at runtime:

but no one cared about it

With the current solution, we will never be informed soon enough about API models changes in our React application. In the best case, we’ll get an undefiend or null error when clicking through the app. However, it’s usually an end user who finds such problems on production. This is definitely not what we want

We can solve this problem by typing API responses with zod. Let’s now see how to do that.

The Solution – zod

Our remedy – zod – is quite a decent npm package with with ~600k weekly downloads. Its GitHub page advertises the library as TypeScript-first schema validation with static type inference.

You can definitely do many things with zod. It can be used together with libraries like react-hook-form to perform complex forms validation. However, in our case, we’ll treat zod as a solution for better typings in TypeScript.

Adding zod to React app

First, let’s install zod into our React application:

npm i zod

First schema definition with zod

With zod, we define our types in a slightly different way. Instead of creating a type or interface directly, we first create a schema. In our case, we can define a UserViewModelSchema using z.object creator function:

Few interesting parts here:

• Line 2: notice how zod helps us to define types like Guid with built-in schemas like uuid()
• Line 8: first, I used AddressViewModelSchema here. This is a custom schema of an AddressViewModel object, which is another type used internally in UserViewModel. You can use such custom schemas in other schemas. Also notice the nullable() call here, which makes the address property nullable

First step done – we have our UserViewModelSchema. But can we use it instead of UserViewModel type? Not really. Schema is used for validation purposes only. We still need the UserViewModel TypeScript’s type.

Inferring type from zod’s schema

Fortunately, zod comes with a handy z.infer function that allows us to infer the type from the schema.

Finally, the userViewModel.ts file looks as follows:

We can use the exported UserViewModel type as previously used type. It’s an equivalent, inferred from UserViewModelSchema.

Validating API responses with zod schema

One last step is to make use of UserViewModelSchema. Let’s modify the getAllUsers function from usersService to validate the data received from the API against our schema:

Notice the usage of z.array. This function call tells zod to validate an array of objects meeting the rules defined by UserViewModelSchema, not a single object.

Now, let’s run our React app and see what happens when we click the “Fetch users” button:

This is awesome! Exactly what we wanted – a schema validation error for API response. Notice how the error message precisely points to the missing (or wrong, in other cases) property. It tells us we expected a number called loyaltyPoints, but instead we received undefined. The reason for this error message is that the loyaltyPoints field is Required in our schema.

After renaming loyaltyPoints to fidelityPoints in UserViewModelSchema and updating the UsersList component accordingly, everything works fine again.

We are now fully typed and prepared for the future, in case an issue with desynchronization of frontend and backend typings happens again

Summary

Today, we’ve seen how typing API responses with zod can help us detect frontend and backend models desynchronization. Schema validation throws errors when the data doesn’t match its expected shape.

Remember that zod is an extended library with many options. I recommend exploring them on your own. An interesting feature we didn’t cover in this article is strict mode, which doesn’t allow additional fields not present in the schema definition when validating the data object.

The open question remains whether to use schema validation on production. One could think that it’s better to not throw any validation errors, because JavaScript may just work. However, I think that throwing an error is always better than silently letting things through. An error lets programmers, automated tests or manual testers to detect the issue before the end user does

You can explore the complete code presented in this article here.

The post Typing API Responses With Zod appeared first on CodeJourney.net.

The title picture of this article shows the end result. If you want to know the solution, keep reading

Context

The context of this need is very simple. I have a unit test in which I want to perform some operations and keep the test running indefinitely afterwards. The use case might be instantiation of an in-memory test server. After that, I want to inform the user (programmer or the one running the test) that the server is up and running. I want to do that before the test finishes. In other words: I want to write the test’s output while it’s still running.

In my case, I was running two .NET Core apps in-memory. The backend server app and the ASP.NET Core web application. In the process, the web app got its IP address assigned dynamically. Meaning that the IP was different with each test run. This particular test was used to run the app in-memory and let the user manually use the application. It means the user must know the IP/URL of the in-memory web app. That’s why I needed to output the dynamic IP address into the NUnit test output

Solution

The solution to write test progress to the console with NUnit is very simple. To do that, use TestContext.Progress.WriteLine(string) method from NUnit.Framework namespace:

And that’s it! I’m publishing this simple solution, because it took me some time to find

I previously tried with TestContext.Out.WriteLine, System.Diagnostics.Trace.WriteLine and System.Console.WriteLine, but all of them output the text after the test finishes.

Finally, you can also run the test from cmd using dotnet test:

Hope it’s useful!

The post Write Test Progress To The Console With NUnit appeared first on CodeJourney.net.

NHibernate.Exceptions.GenericADOException: could not load an entity: 
...
 ---> Microsoft.Data.SqlClient.SqlException (0x80131904): Database 'myappdb' on server 'myapp.database.windows.net' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '{EB501CF2-2F21-4E28-9042-2B83EEE57B91}'.

The database is not currently available was very interesting to me. I struggled a bit with solving that, so if you want to know how I did it – continue reading

The problem

My .NET 6 app is an Azure App Service, and it uses SQL Server database. Quite standard Azure stuff.

The issue was that when opening the ASP.NET web app after some time of inactivity, there was an HTTP 500 error. When I checked the logs, the full error looked as follows:

NHibernate.Exceptions.GenericADOException: could not load an entity: [MyApp.Infrastructure.DomainObjects.ApplicationUser#37931c5a376748d7a49f215ca30283a2][SQL: SELECT applicatio0_.applicationuser_key as id1_3_0_, applicatio0_1_.UserName as username2_3_0_, applicatio0_1_.NormalizedUserName as normalizedusername3_3_0_, applicatio0_1_.Email as email4_3_0_, applicatio0_1_.NormalizedEmail as normalizedemail5_3_0_, applicatio0_1_.EmailConfirmed as emailconfirmed6_3_0_, applicatio0_1_.PhoneNumber as phonenumber7_3_0_, applicatio0_1_.PhoneNumberConfirmed as phonenumberconfirmed8_3_0_, applicatio0_1_.LockoutEnabled as lockoutenabled9_3_0_, applicatio0_1_.LockoutEnd as lockoutend10_3_0_, applicatio0_1_.AccessFailedCount as accessfailedcount11_3_0_, applicatio0_1_.ConcurrencyStamp as concurrencystamp12_3_0_, applicatio0_1_.PasswordHash as passwordhash13_3_0_, applicatio0_1_.TwoFactorEnabled as twofactorenabled14_3_0_, applicatio0_1_.SecurityStamp as securitystamp15_3_0_ FROM ApplicationUsers applicatio0_ inner join dbo.AspNetUsers applicatio0_1_ on applicatio0_.applicationuser_key=applicatio0_1_.Id WHERE applicatio0_.applicationuser_key=?]
 ---> Microsoft.Data.SqlClient.SqlException (0x80131904): Database 'myappdb' on server 'myapp.database.windows.net' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '{EB501CF2-2F21-4E28-2342-2B836E35E891}'.
   at Microsoft.Data.ProviderBase.DbConnectionPool.CheckPoolBlockingPeriod(Exception e)

There were two characteristics of this error:

• it always appeared after some time of not using the web app
• I never reproduced it locally

So it must have been something wrong with Azure.

Transient issues in Azure databases

First thing I did, obviously, was checking Azure App Service logs. This is what I found:

The first recommended step got me curious. To reduce the impact of connection issues caused by future reconfiguration, please implement retry logic in your code.

So I started reading. There’s even official Microsoft documentation for that. It basically says that in the cloud environment you’ll find that failed and dropped database connections happen periodically.

I must admit it seemed quite new to me. However, I started digging into that. I used Polly to implement the retry logic in my app. I found few places where there was an NHibernate query for fetching users executed and wrapped it into the retry policy.

Nothing worked. I was still getting the error. Then, after some talks with my coworkers, we found the real reason behind that…

Solution: Azure database tier

When talking about the issue with my teammates, someone mentioned that the databases in Azure are serverless by default.

I logged into the Azure Portal and checked the “Compute + storage” settings my SQL database my app used:

Indeed, the tier selected was “General purpose (Scalable compute and storage options)” with “Serverless” compute tier selected.

I changed it to “Basic (For less demanding workloads)”:

and… it worked All errors saying that the database is not currently available disappeared. I also removed all Polly-related code for retry policies.

A little explanation

Why do serverless databases in Azure behave like that?

I finally found this explanation in the Microsoft documentation:

If a serverless database is paused, then the first login will resume the database and return an error stating that the database is unavailable with error code 40613. Once the database is resumed, the login must be retried to establish connectivity

That blew my mind! It means that the database is not currently available exception is expected. There’s also another part there:

Database clients with connection retry logic should not need to be modified. For connection retry logic options that are built-in to the SqlClient driver, see configurable retry logic in SqlClient.

Apparently, users of ORMs like Entity Framework should not have to worry about those issues. Unfortunately, NHibernate doesn’t have such built-in transient errors retry logic. That’s why I experienced this particular issue and couldn’t find any straightforward solution online. Simply not many people (if anyone at all? ) experienced this before.

If you want even more details and context, check out this article: SHOULD I USE SERVERLESS FOR ALL MY AZURE SQL DATABASES?

What if I want to use serverless Azure database?

Well… if you really want to use the serverless features of Azure, you might be struggling with NHibernate. As I mentioned, apparently there’s no built-in transient failures retry mechanism in the ORM. There’s one promising solution here. However, currently it’s build for NHibernate 3.3.1.4000, so it doesn’t work with the current version. There’s a Pull Request and an issue opened for upgrading it to the newest version and .NET 6/7. Let’s hope it is done soon.

Otherwise, you can try using Polly as I did initially. However, I didn’t manage to make fully working.

If you have any other idea or solution – let us know in the comments below.

Conclusion

I hope this article saves you some hours of debugging, so you can quickly solve this database is not currently available error in Azure. I wish I found this article on another website few weeks ago

The post How To Fix SqlException Database Is Not Currently Available On Azure (0x80131904) appeared first on CodeJourney.net.

Finally, I found a solution and a reason for that issue.

The error occurred when I was trying to install @testing-library/react npm package. It looked like that:

Hotfix

If you ever get this error, the hotfix is to follow these steps:

• delete node-modules folder
• run command npm cache clean --force
• run command npm install
• install the package again with npm install your-package-name

It should all work fine after that.

If these commands still don’t solve your issue, and you use git as a source control system, you can try the unbeatable git clean -fdx command. After that, run npm install again. Beware – it removes all files not checked in to git. It may also remove your IDE settings etc., so use with care.

But it’s only a hotfix, a solution for now to unblock you.

Coldfix (solution)

The real reason for this issue in my case turned out to be related to jest. However, not to the testing library itself, but to jest extension for Visual Studio Code.

The reason for the issue is the jest tests runner working in the background. You can see that in the VS Code bottom bar:

The real solution is to disable jest runner when installing new packages. You can do it with a Jest: Stop Runner command in Ctrl+Shift+P:

I don’t know exactly why this is an issue. I guess jest runner is blocking some files in node-modules, so they cannot be renamed/processed. I hope it helps you too

The post How to fix: npm ERR! enoent ENOENT: no such file or directory, rename appeared first on CodeJourney.net.

The Asserts Hell

Let’s consider the following unit test:

What’s wrong here? Given and When sections are great single-liners. We know straightaway what’s the input and the action executed. However, Then block is too complex. It’s hard to figure out, just passing quickly through this test, what is expected. This case is even not that bad thanks to the usage of FluentAssertions.

I spend a lot of time writing tests (unit or integration), but I spend even more time reading them. I always hope that I will find these idyllic tests that act as code documentation…

However, let’s go step by step. I recently took place in a software testing course. That’s where I discovered the solution to The Asserts Hell.

Assert Object for Better Asserts

Assert Object pattern is what solves our problem. The idea is to create an Assert class which wraps the original object being tested. In our case the tested object is of Product class, so our assert class will be called ProductAssert.

Let’s see the implementation:

As you can see, we simply moved the asserts from our test’s Then section into ProductAssert class’s methods. Additionally, we always return this from each asserting method, which allows chaining functions calls.

We can now use such assert object in our unit test:

You must agree it’s much more readable now

We can of course improve it even more, for example by wrapping these 3 assertion methods (BeAvailable(), HaveDiscount() and Cost()) into a single one. We can also easily create an extension method for the Product class itself, so the assert object doesn’t have to be instantiated in our unit test. I could even add an extension to FluentAssertions library.

You can find complete source code used as examples in this article here.

Assert Object – summary

I personally find Assert Object a very useful tests code refactoring method. As a programmer, you spend most of your time not on writing, but on reading the source code. Clear and simple tests can make your (and your colleagues’) life much better

Of course, the Assert Object pattern should not be your default way of asserting. If you can complete your test with one or two assertions, then it’s probably better to keep it without wrapping into any additional objects. Having too many assert statements might also mean that the objects being tested are poorly designed. However, as we often work with legacy code which we can’t easily change or refactor, it might be a good solution.

What patterns for writing better tests do you use? Share your tips in the comments!

The post Improve your tests with Assert Object Pattern appeared first on CodeJourney.net.

Today I can say that it was the best decision we could make. TypeScript makes working with JavaScript, which is sometimes surprising and quite hard to understand, so much better experience. However, there were some challenges on this journey. If you want to know what issues we met and how we solved them, but also what huge advantages TypeScript gave us – read on

I will not discuss TypeScript itself in this article. This is a pure recap of challenges and the experience I gained when migrating to TypeScript.

Choosing migration strategy

Before starting migrating to TypeScript, we had to choose the best strategy for this process. There were two possibilities we considered: migrating the whole JavaScript codebase to TypeScript at once or switching to TypeScript compiler and migrating part-by-part.

For those who are not familiar with TypeScript – it is a superset of JavaScript which adds typing information to your JS code. It means that every JavaScript code is also a valid TypeScript code. When compiling TypeScript code, TS compiler removes the typing data and outputs readable, vanilla JavaScript code ready to be executed.

Migrating the whole codebase to TypeScript would mean to change all files extensions to TypeScript ones: .js to .ts and .jsx to .tsx. It would also mean that TypeScript compiler starts checking types in those files. This approach is doable, but – depending on the size of your project – can take a long time. During migration the code would be frozen until you fully migrate the project. Also, for TypeScript beginners, it could be a bit frustrating having to type everything at once or use some tricks to tell TypeScript to ignore checking types in many cases (because the type is not known at this stage, or we want to do it later etc.).

Because of that, we decided to migrate part-by-part, having JavaScript and TypeScript files at the same time. It is possible thanks to enabling allowJs TS compiler option. It means that TypeScript will compile both TS and JS files. Such approach allows the coexistence of old JS code with the new TS parts. It also allows moving only chosen parts of the application to TypeScript at the beginning and come back to the others later.

In our web application the biggest JS files have few thousand lines of code. Some of this legacy code still didn’t use React, but Backbone as their framework. We didn’t want to touch these oldest files in the beginning. Instead, we moved few recently written functionalities to TypeScript straightaway and decided to implement everything new in TS as well.

Bright side of migrating to TypeScript

If you are a JavaScript developer, the best advice I can give you is to start using TypeScript In this section I’m describing what positively surprised me since the beginning of starting to use TypeScript.

Types “for free”

As soon as we changed our transpiler from babel-loader to ts-loader, I wanted to know how we can get typing information for already-installed npm packages. It turns out that for 98% of the packages we used there’s already a typing information available as a separate npm package.

In most cases if you have a npm package called abc there’s a typing package available called @types/abc. I explored our package.json and for each package listed there I just executed npm install @types/package-name. 2 or 3 older or not-so-popular packages didn’t have types definitions available, but for the rest we got types for free, without having to type anything ourselves. This was a first, very nice surprise

You can find more information about TypeScript types definition packages, as well as contribute one yourself, here.

All new code is typed

As I wrote before, every new feature we’ve added since the migration is written in TypeScript. Thanks to that, all new code we write is strongly typed. What’s remarkable here is that it required almost no effort. We just switched the compiler to TS (with a small struggle with webpack configuration, about which you can read below) and suddenly got into typed world for every new feature we implement. Quite impressive, isn’t it?

JS-TS friendship

Coexistence and friendship between JavaScript and TypeScript is HUGE. These two creatures are not enemies – they are best friends We’ve already gone through many scenarios when we needed to use something written in TS in a JS file and otherwise. It turns out that all of these scenarios are manageable. Sometimes you need to import something differently (for example using require instead of import), but it’s all possible. We found it super easy to write new features or even add parts of new features to already-existing JS code, writing everything in TypeScript.

We also rewrote some JS files that were used from multiple places in the app to TypeScript. As an example of JS-TS coexistence, I’m presenting below the potential .ts source code you might have. It contains both old, legacy JS code when we used module.exports and prototype to expose various services for data fetching, as well as a brand-new, nicely-exported TypeScript class:

Such code can of course be in separate files, but it only shows how good TS and JS can coexist together. You can keep your old code working, while implementing anything new in TypeScript.

Flexibility in partial migrating to TypeScript

It turns out that choosing to partially move our web project to TypeScript was a great decision. The team wouldn’t be so happy and enthusiastic about TS if we told them to move legacy Backbone code to TypeScript. Instead, we gave them a nice tool which can be used for all new stuff. Also, if someone likes the idea and wants to move already-existing JS file to TS, he or she is welcome to do so.

That’s how we are still migrating our project to TypeScript, without any hustle and frustration

Wisdom of TypeScript

I’m positively surprised by TypeScript almost every day. At some point I get to the issue that seems hard to be solved or quite non-standard. Then I find a solution online and it makes me really impressed about the job the community and Microsoft has been doing around the language.

These are sometimes small, but smart things. Recently we got surprised by keyof, which lets you get names of the allowed properties of your type. Generally the typing system is really advanced and impressive. For some it can be a disadvantage, but I think it gives an enormous flexibility.

This is somehow the JavaScript you-can-do-whatever-you-want philosophy smuggled into TypeScript But in a much smarter way. I’m sure that when you start working with TypeScript you’ll get what I mean by its wisdom

Small effort, huge benefits

Last, but not least, I must admit that migrating to TypeScript was quite an easy and smooth process. The value for the effort is huge. You get a typed world with very little work.

Migrating to TypeScript struggles

During the migration process we met few difficulties. Some of them we managed to solve fully or partially. If you have any better ideas on these things, feel free to let me know in the comments.

Complexity of webpack configuration

When switching to TypeScript we had few issues with webpack configuration. We have used babel-loader before for transpiling JavaScript and initially we wanted to keep it in the TS compilation process. We first tried to keep babel-loader for JS(X) files and use ts-loader for TS(X) files, but it didn’t work – we were getting weird compilation errors.

Then we tried to compile everything using ts-loader and then recompile it again using babel to ensure (as we initially thought would be wise) backwards compatibility. We also couldn’t make it working.

Finally, we decided to compile everything – both JavaScript and TypeScript files – using ts-loader (including React files). It worked, except source code maps. When we tried to debug in Chrome console it seemed the source code is not refreshing properly after rebuilding. Breakpoints were often not hit and the debugging didn’t seem right.

After a bit of struggling we found a solution. We set devtool webpack option to eval-source-map and configured source-map-loader for .js files. Finally, the proper part of webpack config looks as follows:

So far we also haven’t noticed any issues related to backwards compatibility that were theoretically solved by babel. TypeScript compiler does its job very well.

Complicated JS -> TS refactoring

I found out that JS to TS refactoring is not always an easy task. Some things that are allowed by JavaScript are not valid in TypeScript. In most cases it means that something was wrong with your JavaScript code, but we all know how it is with legacy code refactoring

As an example, we had several functions that we added to a String prototype in JavaScript:

Such code becomes invalid in TypeScript:

A non-obvious solution to that issue is to extend String interface by declaring typed functions you want to add:

There are more subtle difficulties like that you can meet while migrating JS code to TypeScript. However, in the end it gives you a possibility to make your codebase better.

Keeping view models in sync

An issue I didn’t think about before migrating to TypeScript was a need to keep frontend and backend view models in sync.

One of the first things you’d like to have in your TypeScript codebase is to have as much typed data as possible. We use .NET and C# as the backend of our application. ASP.NET MVC controllers returned the strongly-typed objects into the previously chaotic and untyped JS world. Now we are strongly-typed with TypeScript, so we’d like all this data typed as well

Here comes the problem. First of all our C# data models which we returned from the controllers were not the best. In most cases we returned a DTO object which contained many properties from which only few were used by JavaScript code. We never saw this problem, because in JS we just dynamically typed properties names we wanted to use. We didn’t see how much of not needed data is sent from ASP controllers to the web browser.

Now with TypeScript we needed to create these objects definitions also in TypeScript. Having a huge DTO object returned from the controller, with another X objects on which this DTO depends, it was a nightmare. It turned out that for a single DTO I had to create 10-15 TypeScript objects just to use 5-10 properties in the frontend code!

That’s the moment when we came to the necessity of creating web view models. The idea is to return a view model from a controller, not the whole DTO object. This view model contains only the data which is needed by TypeScript (frontend).

I think this is nothing new for experienced web developers. However, now comes the question: how do we keep backend (C#) view models in sync with frontend (TypeScript) ones?

Unfortunately, I haven’t found a perfect solution for that. The best method I came up with is… manually keeping these view models in sync.

There’s a C# to TypeScript VS Code extension which allows to paste the copied C# code as its TypeScript equivalent. It makes the job a bit easier. It even has a CLI tool, but it produces a single .ts file from a single .cs file. If you have multiple objects in a single C# file it will produce a single TypeScript file with all these objects. If any of those objects is used in other files (unfortunately we have many of such cases), these dependencies will not be automatically added as imports in the auto-generated .ts files.

However, I don’t find it very problematic for now. As soon as the TS view models are created, we just need to update them as often as we update C# view models. I think this is a very common issue so if you know any better solution here – please share in the comments

Migrating to TypeScript – summary

Migrating to TypeScript has been a very interesting and rewarding process. Compared to vanilla JavaScript, TypeScript lets programmers see many problems. This allows to see how bad our codebase was. We even realized that our server-side C# code was not the best (see the section about view models above). Thanks to introducing TypeScript we improved a lot of our JavaScript and C# code, including its architecture.

I think that TypeScript uses many simple concepts under the hood and it makes a lot of things possible (see keyof or unknown). In many cases TypeScript lets you do something, but doesn’t force you to do it. That’s the beauty of this typed JavaScript world

The post Is It Worth Migrating to TypeScript? appeared first on CodeJourney.net.

Have Constant Working Hours

Even if you are a freelancer and don’t have constant working hours, plan a time slot during each day when you actually work. I find it best to be a single time slot during a day and the same slot every day. If you prefer, you can try working for a few hours in the morning and then a few extra hours in the other part of the day, but it doesn’t work for me

Working remotely requires you to be very well-organized. It’s not hard to mix up work and private life, so constant working hours are very important to separate them.

If you cooperate with clients or teammates, it’s also easier for them to communicate with you knowing when you’re available.

It might seem encouraging to work for 2 hours in the morning, then go to the beach and promise yourself to finish your job in the afternoon… Been there, done that. I don’t recommend

Plan Tasks for Each Day

In most cases, as a digital nomad, you don’t have a boss or someone who assigns tasks to you. Even if you do, in the end, you sit alone in your hotel or apartment room with no one to punch you and push to work

Sounds like a dream, doesn’t it? Well, not necessarily… At the end of the day, you need to get your job done. Good planning is one of the crucial tips for digital nomads. You should learn to be productive. The first step is to plan your work and to know what you actually have to do on a given day. This also helps to self-push yourself to actually work, despite having a tempting beach nearby

I always recommend to write stuff down and plan your tasks using a suitable and easy-to-use tool. Personally, I use Nozbe for that, but it can as well be any other tool that you feel comfortable with. I believe that as digital nomads we don’t use offline paper notebooks anymore for tasks management

Seeing a list of a few tasks for the coming day tells you that you actually need to do something.

Use Do Not Disturb Modes

When your boss or team leader is not looking over your shoulder, why don’t you spend some more time on Facebook or Instagram? I often do find myself opening an interesting website like that just to check what’s happening and “accidentally” spending 15 minutes there… Sounds familiar?

From all the tips for digital nomads I can give you, I find two particularly revealing. The first one is disabling all notifications on your smartphone. Simple as that – just disable them for all apps you have installed (maybe except phone and calendar apps if you use them). Instead, plan some reviews of your email, tasks apps, Facebook and Instagram a few times a day. Thanks to that, you’re not disturbed when working. I also found a Wind Down mode which my OnePlus suggested to me after the recent Android update:

It allows you to configure your phone to enable a grayscale (which is apparently good for using the phone before sleeping) and Do Not Disturb mode during defined hours. It might be a great idea to enable it while working. There’s also a similar feature for iPhone.

The second tip for eliminating the disturbances when working is disabling or restricting access to non-work-related websites. I’m using a Rooster for Chrome extension. First, a light way in which you can use it is just to install it and see on each new browser tab you open how much time you spent on given websites today. It can be eyes-opening during your working day The more hardcore way of using this tool is to define a time limit for each website. If you spend more time on a given site, it yells with an alarm. Can be helpful if you can’t manage it yourself

Have a Separate Place for Working

I literally mean it. If you work from home, hotel room or apartment, find yourself one physical place from which you work. If you start working in the second part of the day as I do (because of time zone differences – more about it below), you might do something not related to work in the morning. Even now, I’m writing this blog post before starting my actual work. I find it helpful to sit on a different chair when I start working. Really, it helps

I try to always have a single physical place (like a chair in a given position related to the table) in the place I live in only for working. Even if switching from blog posts writing to working is only moving a chair to another side of the table, it allows me to enter work mode. It’s like coming into an office and sitting by your corporate PC Just try it yourself and let me know if it does the job for you!

Change your work environment

Apart from having a constant place for working, it’s sometimes very useful to change the environment in which you work.

I normally work at the place we rent for living. We tend to stay in a given city/country for longer – normally at least 2 weeks, sometimes a month or more. When looking for accommodation we always find something with a table and a chair with a back. We don’t want to be dependent on co-working spaces or cafes.

However, after working from “home” for a few days in a row I see that my productivity decreases. I start going around, visiting all these interesting non-work-related websites more often and just getting angry with Rooster yelling at me When such a day comes, we normally plan a visit to a cafe for working, at least for a few hours. Having people around looking at me makes me suddenly much more productive I wanna look like a real digital nomad, so I can’t have Facebook open when they look! There must be some crazy code at my screen so I look like a hacker

You can also try going to a co-working space. I’m not a big fan of them, but co-work can be a very good place to socialize and also focus more on your work.

Be prepared for different timezones

Being in your home country and occasionally traveling, you may not realize how timezones can affect your life. And I don’t mean having a jet lag from time to time

Most of my life, I used to work in the mornings, normally for 8 hours a day. When we started our round-the-world journey in June 2019 and finally moved to Southeast Asia, the timezones came into play. The time difference between Poland (where the client I currently work for is based) and SEA is 6-7 hours. I have to be in quite a constant contact with my teammates and our final customer (also from Europe). Because of that, I had to change my working hours and start work at 12 PM (noon). It totally changed how I organize my days now and how I manage my productivity.

Don’t treat different timezones as a bad thing. Just make proper use of them and plan your days accordingly. I imagine it might be even harder if you do some freelancing and have many customers from different parts of the world. Or maybe it’s easier in such a case because these customers are used to an asynchronous and distributed working style? Let me know in the comments if you are in such a situation!

Embrace yourself for unexpected issues

There might be dozens of tips for digital nomads, but unexpected always happens. Especially if you are used to having a fast, stable Internet and uninterrupted electricity When working while traveling and often changing places, you need to be prepared for unexpected issues that you don’t normally think about being home.

In Southeast Asia, power outages are a normal thing. No one cares if there’s no electricity for 3 or 4 hours. Well, except you who needs it for work Be prepared to control your emotions when such a thing happens. You will quickly find out that there’s no one to blame for that – even if your AirBnb’s listing mentioned constant electricity access It’s better to accept it and focus on a solution. Go to a cafe or a co-working space during this time. Always have your laptop’s battery and a power bank fully charged.

The same applies to the Internet. We often found ourselves booking a stay for a few weeks and then realizing that the Internet is very bad… Sometimes I couldn’t even comfortably take part in an online video meeting that we have with my team every day. At first, I was getting very angry blaming myself or hosts of the guesthouses we stayed at for it. I was sometimes driving a scooter through the island to find a place with good Wi-Fi. With time, I learned to accept it Now I always have a mobile Internet data package ready for such cases. If it fails, I simply say sorry to my teammates and they understand. The world doesn’t end if you miss one meeting

Learn to Communicate Asynchronously

Last, but not least – communication Working in a physical office makes it easier to find someone and talk to them. Even working remotely, but in the same timezone, it’s easy to call someone directly.

However, being a digital nomad assumes that sometimes you’re not in time sync with your teammates or clients. Amongst many tips for digital nomads, an important skill to possess it asynchronous communication.

If you communicate via standard means like email or text communicator, write simple and straightforward messages. It should be understandable, not too long and focused on the goal (getting an answer). Emphasize that you are expecting concrete answers which will move your work forward. You can even say that if you don’t get the answer, you’ll be stuck with work.

It’s important to prepare others that when they answer your question with another question it doesn’t help you. Asking asynchronously means that you leave a message now and are expecting an answer later. Later – this is an important keyword here. You may leave a message when you finish work and are expecting to have an answer when you start to work the next day. Your colleagues might be asleep this time and you’ll have to wait another few hours for them to be online again. It takes time and practice to get it right, but it’s worth working on it

The good thing about asynchronous communication is that the exchanged messages do not require an immediate answer. That’s the goal, but as I mentioned above you need to set up some boundaries on when you expect to get the answer to not block your work. I also really like the idea of task-based communication. If you use a task management system at work you can try communicating as Nozbe guys do.

Do you have any other tips for digital nomads you can share? How do you make your days better organized? Let me know in the comments!

The post 8 Productivity Tips for Digital Nomads appeared first on CodeJourney.net.

What is a widget?

If you ever worked with a web framework like React, you should know the concept of components. Flutter widgets are directly inspired by this idea. Widget is a reusable piece of code, which describes how your application’s UI looks like. Widgets define the user interface by their state. In some cases, the state can be static and not change over time – see the section below about Flutter widget types for details.

As soon as a widget’s state changes, Flutter rebuilds its outlook and in effect re-renders the GUI. The framework is said to do it efficiently by measuring what has changed in the widgets tree since the last rendering and re-paints only what’s necessary.

The most basic Flutter app might look as follows:

The runApp() method takes a Widget as its argument. In our case, it takes a Center widget, which has one child – a Text widget. As expected, such a simple Flutter app shows a “Hello Flutter!” text at the center of the screen.

This simple example shows us a few interesting facts:

• there are many built-in widgets, like Center and Text
• widgets can have a child or children – this is widgets nesting and it happens all the time and can be very deep
• Flutter widgets can have their own properties, like textDirection.

Widgets nesting sometimes makes simple Flutter apps having a lot of source code inside a single file. However, as I mentioned in the previous post, don’t get discouraged by that Actually, having a lot of nested widgets in Flutter is a good practice. If you have a few huge widgets without much nesting instead, it means that there’s something wrong with your implementation. Flutter widgets – as all reusable pieces of code – should not have too many responsibilities. SOLID also applies here

Viewing Flutter widgets with Flutter Inspector

As widgets tree may get big and quite heavily nested, there’s a very useful tool to easily view and explore it. This tool is called Flutter Inspector.

While in debug mode in Visual Studio Code, you can launch it by clicking the blue magnifier icon:

It opens in a web browser and allows you to see the whole widgets tree in your app:

There’s a very handy feature “Select Widget Mode” which, when enabled, lets you select the widgets directly in your emulator or phone. After doing this, you can see the selected widget’s properties in the inspector.

Types of Flutter widgets

In Flutter, you can – and will – create your own widgets. Widget is just a Dart class which extends a proper base class. Depending on whether your widget actually manages any state and changes over time, you have two types of base classes to inherit from – StatelessWidget or StatefulWidget.

The main purpose of each type of widget is to provide an implementation of a build() method which returns a Widget object. However, each widget type does it a bit differently. Let’s see this in action.

StatelessWidgets

The simplest widget you can create is a stateless widget. You create it by simply creating a class extending StatelessWidget. Here’s the sample source code and a view it generates:

	import 'package:flutter/material.dart';
	void main() => runApp(
	MaterialApp(
	title: "My CodeJourney Flutter app",
	home: Scaffold(
	appBar: AppBar(
	title: Text("My First App"),
	),
	body: MyFirstWidget(),
	),
	),
	);
	class MyFirstWidget extends StatelessWidget {
	@override
	Widget build(BuildContext context) {
	return Container(
	padding: EdgeInsets.all(8.0),
	child: Text(
	"Hello MyFirstWidget!",
	style: TextStyle(color: Colors.green),
	),
	);
	}
	}

view raw main_stateless_widget.dart hosted with ❤ by GitHub

You can play with it yourself in the DartPad.

There are quite a few new things in the source code. Let’s point them out:

• as our main widget, we used MaterialApp and provided it to runApp() method. MaterialApp widget gives us material design for our app out of the box. As soon as you use it, you can nest more material widgets from the widgets library. There’s a similar widget for Apple-oriented widgets called CupertinoApp, which allows using Cupertino widgets
• we used another material widget – a Scaffold. It provides us with an appBar and body properties – setting them we’re getting this nice-looking application’s skeleton with entitled app bar and home for our widget. Scaffold also gives us many things “for free”, e.g. FloatingActionButton
• body of our Scaffold is our first own stateless widget – MyFirstWidget. As mentioned before, it overrides the build() method, which simply returns another widget tree. Notice the usage of a Container widget, which is very useful for grouping other widgets.

StatelessWidget is simple, works and is just there Let’s see something more interesting now – StatefulWidgets.

StatefulWidgets

When you want your widget to change over time and maintain its state (in most cases you do), you can create a stateful widget. You do it by creating a Dart class extending StatefulWidget. Unlike StatelessWidgets, StatefulWidget doesn’t override the build() method. Instead, it implements a createState() method, which creates the initial widget’s state (see below).

Apart from the main widget class, which itself is still “final” (or better said – immutable), you create a class extending State. This class maintains the actual state and it is now who provides the build() method’s implementation.

Let’s see the sample code and produced GUI:

	class MySecondWidget extends StatefulWidget {
	MySecondWidget({Key key}) : super(key: key);
	@override
	_MySecondWidgetState createState() =>
	_MySecondWidgetState();
	}
	class _MySecondWidgetState extends State<MySecondWidget> {
	int _clickCount = 0;
	void incrementClickCount() {
	setState(() {
	this._clickCount++;
	});
	}
	@override
	Widget build(BuildContext context) {
	return Scaffold(
	appBar: AppBar(
	title: Text("My First App"),
	),
	body: Container(
	padding: EdgeInsets.all(8.0),
	child: Text(
	"Hello! Times clicked: "
	+ this._clickCount.toString(),
	style: TextStyle(
	color: Colors.green,
	fontSize: 20.0),
	),
	),
	floatingActionButton: FloatingActionButton(
	child: Icon(Icons.add),
	onPressed: this.incrementClickCount,
	),
	);
	}
	}

view raw main_stateful_widget.dart hosted with ❤ by GitHub

The full code you can play with is available in the DartPad.

Now some comments about the StatefulWidget code:

• notice how MySecondWidget class passes a key to its superclass. Concept of Flutter widgets keys is interesting and we’ll dig into it in a separate post. For now, just treat it as a convention to always accept a key as a named argument and pass it to the base class
• as said before, in this simple example, MySecondWidget only creates the initial state by instantiating _MySecondWidgetState
• you’re already familiar with most of the code in _MySecondWidgetState, but notice the usage of setState() in incrementClickCount() function. It tells Flutter that the state has changed, so the framework can re-render the UI. If you directly change the value of this._clickCount without calling setState(), GUI will not be updated until setState() is called in some other place. We’ll talk more about state management techniques in Flutter in the future articles
• note how easy it is to add a FloatingActionButton thanks to using Scaffold material widget.

That was easy and works nicely! You now know how to use both Flutter widget types

Flutter quick actions in VS Code

I’d like to share with you two easy tips for working with Flutter in Visual Studio Code. Both speed up the development nicely. It assumes that you configured VS Code properly (if not read this article) and have Flutter extension installed.

Ctrl + .

First important keyboard shortcut is Ctrl+. (Cmd+. on Mac). It allows you to perform many element-contextual actions. For me it’s most useful for removing widgets or wrapping widgets with other ones:

Snippets for widgets creation

Another useful feature are code snippets for creating widgets. You use them by starting to type their acronym in your .dart file. There are two acronyms for widgets creation – stless for StatelessWidget and stful for StatefulWidget scaffolding. The usage looks as follows:

Most popular Flutter widgets

I wanted to list you here some most popular Flutter widgets, but they are quite well described here. You can also search through the widgets library. We’ve also used quite few of them in our examples above

Community widgets

Many more people are starting to use Flutter and they also create a lot of community widgets. You can find the Dart packages for Flutter on pub.dev. I also recommend checking the Flutter Awesome website where the best Flutter widgets, libraries and other extensions are listed.

Summary

That’s it! You’ve just learned how to use stateless and stateful widgets in Flutter. We’ve also seen what’s the difference between them and what are some basic conventions in creating them. There’s a lot more to Flutter widgets and related topics, but these are topics for separate posts. I hope to publish more of them soon

In my opinion, bringing components into the mobile world in the form of widgets is a very nice idea. They give quite a good separation of logic and GUI management. For sure it’s a fresh start, totally changing the way in which we think about mobile apps development. Components have done their job in the web world, so why would widgets not succeed in mobile apps? We’ll see!

What do you think? If you are interested in some particular topics related to Flutter – let me know!

The post Basics of Flutter Widgets appeared first on CodeJourney.net.

What is Flutter?

Flutter is an open-source platform and development kit created by Google. You can use it to create mobile (Android, iOS), desktop (Windows, Mac, Linux) and recently also web applications.

Flutter is quite new, as it’s first official version 1.0 was released in December 2018. Before, it was developed and used internally by Google for a few years.

Since this time, countless Flutter apps have been published. You can find their list for instance here. One of the most well-known Flutter apps is Xianyu app created by Alibaba and used by 50M+ people.

The main purposes of Flutter are claimed to be fast development, beautiful and consistent UIs and native performance on each platform.

Dart as a programming language

Flutter uses Dart as a programming language. Why is that? Well, of course, Dart is also developed by Google However, one of the real reasons is believed to be performance.

As you probably know, Flutter is not the first (and not the last) cross-platform mobile development platform. Its main competitor is React Native, which uses JavaScript. Dart compiles to the given platform’s native machine code. Thanks to that, it doesn’t have to use a JavaScript bridge to interact with native components that React Native apps have to do. I don’t know how true this is in real life and how it helps with performance, but that is one of the reasons for using Dart as a programming language for Flutter apps.

Dart is a UI-oriented language. For C/C#/Java developers, Dart’s syntax will be rather familiar and easy to learn. It’s object-oriented, including support for classes and interfaces. The language is type-safe, meaning it combines static and runtime types checking.

Dart is supported by its virtual machine, which also provides – amongst others – a garbage collector (if you don’t know what the GC is, check out this post).

Here’s a simple program written in Dart:

You can play with the code yourself in the DartPad.

Another interesting feature that is possible thanks to Dart is the hot reload. We’ll explore it later, but it significantly speeds up the development and testing time.

If you want to learn more about Dart, check out the official docs.

Everything as a widget

The main concept in building Flutter apps are widgets. In Flutter, everything is a widget – buttons, texts, menus, colors, themes, spacings and paddings. Even your Flutter app is a widget.

What’s very interesting is that Flutter doesn’t use platform native widgets. Instead, it provides its own set of widgets for each platform, e.g. Material Design for Android and Cupertino widgets for iOS. Additionally, as a programmer, you can create your own widgets. Thanks to that, all Flutter apps look pretty much the same on every Android/iOS version. You don’t need to worry about some UI elements changes between OS releases. At the same time, an app built using these widgets looks like native GUI.

Thanks to the widgets concept, Flutter apps can be easily personalized and branded. Recent researches show that customers are now starting to prefer more specific-looking apps to standard and boring native-designed UIs.

The drawback which I see about widgets is that there’s normally A LOT of source code in Flutter apps. Don’t get confused straightaway

Installation and configuration

Now, let’s get into the real work. It surprised me how easy it is to start working with Flutter. As you’ll see in a moment, you can build quite a nice-looking mobile app with Flutter in less than 30 minutes!

There are several possibilities to work with Flutter. You can easily set up Android Studio or IntelliJ. For example purposes, we’ll focus on running and debugging an Android application on Windows PC using Visual Studio Code. If you’re on Mac or Linux, check out a corresponding official installation guide.

Install Flutter and Android SDK

The installation process is quite easy. Initially I wanted to describe it here for you, but actually the official installation docs do it pretty well I’ll just guide you through the steps below with links to the official installation guide.

Install Flutter SDK and Android Studio

First of all, install Flutter SDK and Android Studio (which is required for Android SDK) following this installation guide. The process is fairly easy and should not take more than 15 minutes. Remember about using flutter doctor command to verify if everything is installed correctly – it gives very clear messages. In the end, using VS Code and having Android phone connected in USB Debugging mode, your flutter doctor command should have an output similar to mine:

Configure Visual Studio Code

The next step is to configure Visual Studio Code to be able to develop, compile, run and debug Flutter apps. You only need to install the Flutter extension, which is very well described here. It should also automatically install the Dart VS Code extension which adds Dart language support to VS Code.

Your first Flutter app

Now let’s finally create this first Flutter Android application It’s probably gonna be the quickest part!

Create and run a sample app

First of all, open Visual Studio Code. Use Ctrl+Shift+P to open a Command Palette. Start typing “Flutter” and select Flutter: New Project:

In two next steps specify your project’s name (e.g. “hello_flutter”) and choose a location where the template should be generated.

Wait until VS Code generates the whole project and you see main.dart file in lib folder:

Open the main.dart file and replace its contents with the following, a bit cleaned-up code:

We won’t focus on the source code here – I hope to dig more in the coming posts Just notice there are quite a few widgets – can you count them all? I found at least 12 different widgets used in this small template code.

Now the best part – having your Android phone connected (you should see it in the right-bottom corner of VS Code) press F5 to run the application. After a few seconds (usually longer for the first time) you should see this beautiful application on your smartphone’s screen:

As soon as you press the “+” button the green counter increments. Yaaaaay!

Debug your Flutter app

Now, try putting a breakpoint in main.dart file at line 30 (beginning of _incrementCounter() function). When you click the “+” button next time, VS Code should stop at the breakpoint:

Try hot reload

The best for the end. As I mentioned before, Flutter lets you use a hot reload. It lets you change the code while running the app and see the changes immediately after saving the source code file. I love it especially because it’s a stateful hot reload, meaning that except UI the state is also reloaded (or rather kept).

With your Flutter app running in debug mode, click the “+” button several times so the counter has value > 0. Then go directly into VS Code and modify line 50 by changing the counter text color from Colors.green to Colors.red. Line 50 should now look as follows:

Save main.dart file by pressing Ctrl+S. Take a look at your smartphone and see the magic:

Notice how the color of number “7” (counter value) changed to red while its value remains untouched. Quite a nice feature for quick development

I noticed that sometimes it doesn’t work that smoothly and you need to restart the app to see the changes. However, it happens only with some bigger code changes. Flutter quite young SDK and tools are still developing quickly so I hope such drawbacks will be eliminated soon.

Summary

Today we’ve seen how easy it is to start working with Flutter. We got familiar with basic Flutter concepts like widgets. We’ve also created our first Flutter app and debugged it. Finally, we’ve seen the very cool hot reload feature in action

For me, Flutter looks promising. After my adventures with Xamarin, which mostly felt like changing Java to C# and Android Studio to Visual Studio, I’m excited to try something fresh and totally different.

I know this was just a simple introduction to Flutter, but there’s more coming! I hope to publish the next articles about Flutter as I continue playing with it. If you’ve ever used Flutter and have some good sources to recommend – let me know in the comments!

Stay tuned!

The post Your First Flutter App in 30 Minutes appeared first on CodeJourney.net.

Today I’m trying to address the issue of approaching an unknown codebase. I’ll give you some advices and tricks I’m using to make new code easier and quicker to understand – even without understanding it all

Understand the architecture

For me, the first thing to do in a new project is to understand the software architecture. My goal here is to as quickly as possible find answers to the following questions:

• what is a client? Is it a desktop, mobile app or both? Maybe there’s only a web app, but used on different devices?
• what is a server? Is it a single instance or some distributed service? Where does it run?
• how do the client and the server communicate? Is there any framework used (e.g. WCF) or maybe just some RESTful web service communication?
• are there any architectural design patterns used by the team in both clients and server apps (e.g. Layered Pattern, MVC, MVVM, CQRS…)?
• what are the important frameworks/libraries used in the clients and server apps? By important I mean these ones which directly define the style of coding, for instance: ASP.NET MVC, WPF, Caliburn.Micro, Prism, Spring, Angular, React, TypeScript etc.

Answering these few questions will give you a feeling of where is what When working with some tasks you’ll automagically feel where the issue may be or where to look for a solution (or problem ).

It’s sometimes helpful to draw the architecture on a paper or whiteboard to help you easier grasp the elements and connections between them.

Learn the persistence

Each application stores its data somewhere and you should know where and how it does it. At least it’s a bit helpful

First of all, find out what kind of database is used by the software. Then check how the applications (clients, server) communicate with the database. In other words: find out in which place the queries are sent to the database. I really mean it – if SQL db is used, find out where exactly the SQL statements are generated and sent to the server. Maybe there’s some ORM (like Hibernate/NHibernate or Entity Framework) used for that?

Next, find out how is the persistent data (e.g. tables) represented in code. Where are the persistent classes defined? How are database restrictions (not-null fields, primary and foreign keys, constraints, data types) defined on them? How are the objects’ fields mapped to database tables’ columns?

In the end, try to understand how these persistent objects are presented in the GUI. Are there any DTO objects used? How is a business validation (e.g. maximal length of a field or email validator) defined for these objects (maybe some validation library is used)?

Knowing the persistence layer and its functioning in the software will help you work with your new, yet unknown codebase. You can often be assigned to issues related to database limitations or business validation and knowing where is what can significantly ease your pain

Learn to deploy your system

It may sound obvious, but you should quickly learn by heart how to deploy your system (or part of the system you are working on) from scratch.

Compile the whole code and learn how to run it all (server and all clients). If possible, start with a clean database as a new customer would. If the process is complex write down the step-by-step instructions while your colleague explains the process to you. It’s very important that you practice it yourself and finally are able to go through this “deployment” process even without your notes.

Know the system functionally

Among the first steps for approaching an unknown codebase you should… put the code aside and focus at least a bit on the functional side.

As soon as the whole system is running, spend some time clicking through the application. Try to grasp how it works, what’s the feeling of the system.

If possible, find someone who has functional knowledge about the software – preferably a consultant or customers’ trainer – and ask him/her for a live demo. It would be best if they can give you an introductory demo as they do for end customers. Ask as many questions as come to your mind during such a presentation. If possible, leave some communication channels open with the person who trained you, e.g. a chat where you can leave your potential doubts/questions. Ask him/her to answer them from time to time. Also, check with the presenter if there are any resources on the problem domain of the system.

The better you understand the problem domain, the better your technical decisions are going to be. Sometimes you don’t need to understand everything – even consultants or designers may not always know what clients are really using the system for. However, it’s important to understand as much as possible from a functional point of view. Such a perspective helps you think differently when you’re asked to implement a feature that initially sounds like nonsense. Maybe that’s really what customers need to solve their domain problems?

Explore source code tests

This part becomes more meaningful when you’re assigned your first tasks. I don’t recommend exploring all the tests in your application before you start working – except if these tests are veeeeery good and really human-readable (which I’ve honestly never seen so far ).

As soon as you’re starting to work on some task you may have the feeling that you completely have no idea how the related part of the software works. If that’s the case, try to look for tests (unit, integration tests) in the code related to this feature. If your “issue” is related to a need to make some changes in a particular method, try to find this method’s usages – hopefully, it’s called by some tests:

Exploring the tests can give you an idea of what an author-developer had on his/her mind when writing this code.

Of course, as soon as you make any changes in the code, run all tests to make sure you didn’t break anything Especially the tests related to what you’ve changed. The best obviously is when you have a build server that runs the tests for you.

Have software documentation around

If there’s any documentation for your new software – have it somewhere around. Don’t read it – except, again, if it’s veeeeery good and interesting (anyone has ever seen such docs?! ). Just keep it in case you need to find out how something works. You can always search such documentation by phrases/keywords related to the task you’re working on. Maybe it’ll help you to at least reproduce the problem

Document your actions

When I work with an unknown codebase I tend to keep track of what I’m doing. This is also one of my productivity tricks. I create a new project in Nozbe (tasks/projects management application which I’m using) for each task I start working on. It can also be a new Notepad file, a new tab in Sublime Text or just a piece of paper. In such a place I write down what I’m currently working on. If I have some exception’s stacktrace I’m trying to analyze – I paste it there. I write down some objects and try to picture the relations between them.

Simply writing down stuff in a “natural language” often helps me find a solution quicker. Have you ever started to ask someone for help and as soon as you explained to him/her your issue, you suddenly got an idea of how to solve it? It works similarly with writing things down – it’s like explaining stuff to yourself. Just give it a try

Debug

Obvious, right? Well, not necessarily. I often see people debug only when they know exactly what to debug. When working with an unknown codebase I find it helpful to break through the application’s startup. Put a few breakpoints in one of the application’s entry methods and debug how it launches and initializes line-by-line.

It will help you to see what components are used and how are these loaded.

Do the same with given actions you want to understand. If there’s some button that causes an issue later on (not directly after pressing it), put a breakpoint in a method that is assigned to a button and try to debug step-by-step until the exception is thrown. It will let you understand how the codebase is built and what the developer exactly intended to do with this button.

Search literally

I think most of us do that, but very few confess

When working with an unknown codebase I very often search for things literally. For instance, when working on an issue occurring on pressing a button it may not be easy to find the code-behind the button (a method which executes as soon as you click it). In such a case, I just copy the text which is a button’s text or name and search by it literally in the whole codebase. It can even be one of the translated resources – their values are often stored somewhere (e.g. in XML files). This often allows to quickly identify a method attached to the button just by finding the string or the translation key’s usages

If you don’t have any GUI element with text to search for, try to search by intuition For example if you’re trying to find a code that handles saving a document, just search by strings like “SaveDocument”, “AddDocument”, “UpdateDocument” etc. It can greatly help you find what you need!

If you’re using Visual Studio with ReSharper there’s a really useful “Search everywhere” feature which allows you to easily search strings literally in the whole solution:

Don’t be afraid to ask

Not asking is a common issue, especially amongst experienced developers. Programmers are often afraid of asking questions. New guys in a team tend to think that it would be a shame to ask someone for such easy stuff… But hey, you’re new in the team and it’s perfectly fine to ask for anything that comes to your mind!

I’d say even more – by asking questions you show your engagement and a will to really understand what you’re doing. Sometimes digging into an issue ourselves can be much longer than doing it with a little bit of help from the project’s seniors. So by asking them to aim you in the right direction you’re also saving yours and your company’s time

When working as a team leader I preferred to have people in my team who asked questions to silent on-my-own geeks. Of course, you should first try to find the solution yourself, e.g. using one of the tips described above However it’s always better to ask and get the answer or be aimed in the right direction in 5 minutes than spending the whole day fighting with the problem. It would also make your day much better

Summary

I hope these few tips will be useful for you

Don’t be afraid of an unknown codebase. Don’t try to know it all straight away – you don’t need to and even shouldn’t If the codebase is huge, you’ll potentially never know it all. Just grasp the main concepts and architecture. Be in touch with your teammates and don’t be ashamed of asking them questions – with time, you’ll ask less

I think that one of the factors showing a developer’s experience or seniority is the ability to work with code he/she doesn’t know. Very often to fix a bug you need to change a single line of code. The trick is to find that line

I’m very curious what are your techniques for approaching an unknown codebase? Do you have some tricks to quickly find yourself in legacy code you don’t know? Share your tips with us in the comments!

The post How to Start Working with an Unknown Codebase? appeared first on CodeJourney.net.

I’d like to show you how software development – and this blog! – helped me starting a completely new life

Who is a digital nomad?

I’m sure you’ve already came across the term digital nomad. I won’t give you the exact definitions, as I think this term is already overused nowadays. For me, being a digital nomad means to be location-independent while still being professionally active (either by generating active or passive income).

So, enough theory

Why have I become a digital nomad?

As you can guess from this article’s title, I can now call myself a digital nomad. So why have I decided to become a location-independent person?

As you could read in my post about renaming this blog to codejourney.net and also on my about page, I’ve been a huge traveling addict for some time. It also turned out to be my and my wife’s common passion. With time we also created an Instagram account and traveling blog in order to show our travels to others and – hopefully – inspire them to go for their own trip. During our last year’s trip to Thailand, we met a lot of people who traveled and worked remotely. Then we thought: “hey, why won’t we connect traveling the world and working?”

What’s more, we’ve never been attached to things or places and we thought that our casual, everyday life was just boring. We needed a change.

We didn’t (and we still don’t) have our own flat, children or mortgage, so there was literally nothing really stopping us from dropping everything and going.

Finding a remote job

The most important thing to make this dream come true was to find a fully remote job. To be honest, my previous job (I worked as a .NET Developer and Team Leader) was very good and challenging. I really liked it. I also met there a lot of people who pushed me forward and allowed me to develop – both as a developer and as a person. Unfortunately, it was not possible to work remotely for this company so I needed to find a 100% remote position.

Remote working in Poland is still not as popular as in the other western countries. Despite that, I managed to find a new job in one of the Polish software houses. It was quite a change for me, as currently I’m not managing a team anymore, but I’m back to pure programming. So far it feels awesome I missed full-time programming a lot! Such Team Leader – programmer transition is a separate topic – let’s keep it for another article.

I started working for a new company still being in Poland. It allowed me to go to the office physically and meet the team I’m working with now. It helped a lot.

Programmer – perfect remote profession

The ease of finding a remote job was of course because of me being a programmer. Software development is currently probably the best profession to find a remote position in. I’m lucky enough to be a developer and I’m really grateful for that. I’m aware that becoming a digital nomad may be much harder for people working in another industries.

However, not only programming helped me turning my life upside down. There are many aspects around programming community which helped me even start thinking about such a decision. Lot of people I met at work or at the conferences were also engaged in personal development topics. My colleagues often recommended me to follow some inspiring people. I’m pretty sure that if I didn’t work in IT, I wouldn’t develop that much as a person. I wouldn’t start following and getting inspired by a lot of people mush wiser than me. So, IT community – thanks for that!

Role of this blog

Last but not least, this blog – and all of you, my dear readers – helped me a lot in becoming a digital nomad and starting this new life I dreamed about. Conducting a blog gave me a lot of confidence. I’m very happy that many of you find my articles helpful. You often ask questions and start discussions, both in the comments and via email. This really makes me feel that the time I spent here (not much recently, but I hope now you see why!) is not lost Thanks a lot guys!

What’s more, for the last 1-2 years I’ve been getting more and more involved in team management tasks at work. This blog helped me to always stay up-to-date with programming and technology. It definitely made my “coming back” much easier and less painful

Dropping everything with one-way ticket

Long story short, that’s how on 13/06/2019 we dropped everything and started a world-trip with one-way ticket. Our first stop is Georgia (the country). We’re staying here for few months and will then move further to the next countries. We have no coming back date. Our plan is no plan at all

I’ve already been working fully remotely for 1 month. So far so good

Summary

I know that everyone has his/her own lifestyle and I don’t want to encourage you to do the same what I did. However I encourage you to not be afraid of taking serious decisions in your life. Stop caring about other people’s opinions – you have only one life and no one will live it through for you

I’m just an ordinary guy who wanted to change his life and managed to do so with some work and appropriate attitude. I think that everyone deserves a life he/she wants to have. If you’re motivated enough and ready for hard work, you can achieve a lot. Just do it!

If you want to stay up-to-date with our traveling and remote working adventures, I invite you to follow us on Instagram and our traveling blog – for now, it’s only in Polish, but we hope to add English captions to our feed photos soon.

Have you ever worked remotely? Did you connect it with traveling? Maybe you have some digital nomads spots to recommend in Europe or Asia? Share your thoughts in the comments!

The post How Programming Helped Me Becoming a Digital Nomad appeared first on CodeJourney.net.

How will this possibility change the way we write C#? Why is it being introduced? I’ll try to address these questions today

Interfaces today

As we all know from the current version of C#, interfaces allow to define a kind of contract, which must be respected by a class implementing it. Today interfaces can only contain definitions of methods (with no body). These methods are then actually implemented by concrete classes. If a class doesn’t implement all of its interface’s methods, compiler produces an error.

What’s problematic in this approach? Assuming that you have the following interface and class(es) implementing it:

With time, you may want to extend IDeveloper interface by adding a new method, for instance:

Now you have a problem, because the new method must be implemented in all places where the interface was used. Compiler gives you an error as long as it’s not done:

If your interface is used in many places, also by another teams or developers (which is often the case in reality), this is a breaking change

It may be really painful, depending on how extensively your interface is used. In any case, all classes based on the IDeveloper interface must implement the new LearnNewLanguage(string language) method. Only then the code compiles.

One of the reasons for introducing into C# default interface methods is to avoid such breaking changes scenarios

Default Interface Methods

As we can read in the feature’s design notes, an inspiration for it is a similar concept already alive in Java – Default Methods.

The main idea of this new C# feature is a possibility to provide a default implementation of an interface’s method.

Realization in C# 8.0

In our example using C# 8.0 we’ll be able to implement it as follows:

In that case, our class implementing the IDeveloper interface can legally not implement this new method and there will be no compilation error:

Notice that it only works when BackendDev is contextually treated as IDeveloper. It means that a class doesn’t inherit members from the interfaces it implements:

What about multiple inheritance?

As some of you probably realized, this new feature exposes C# to a multiple inheritance problem (also known as Diamond of Death). So far C# didn’t have this issue, because we can only inherit from a single class. We can implement multiple interfaces, but so far the interfaces couldn’t provide methods’ implementation. Because of that, there was no Diamond of Death possible. Soon it’s gonna change

Diamond of Death in C# 8

In case of C# default interface methods we may illustrate this issue with the following code:

Please note that the syntax or places in which compiler generates errors may still change in the final feature’s version.

To better illustrate this Diamond of Death example, take a look at the following diagram:

The question is: which method should be called in such case?

Solution: most specific override rule

C# 8.0 will solve this issue by introducing the most specific override rule. It means that in our case illustrated above, the compiler will issue an error and won’t let us do this.

To avoid this ambiguity, we’ll be forced to implement or override LearnNewLanguage(string language) in IFullStackDev interface. Only then it will be considered the most specific version of the method in the interfaces hierarchy we have. It will then be used when calling the method on objects contextually treated as instances of IFullStackDev. We could also implement it directly in the Dev class and use the class (not interface) type. It would then call the most specific method from the class. This way multiple inheritance issue will be eliminated.

Compiler for the rescue

There are a lot of other potential ambiguity scenarios that may take place after introducing into C# default interface methods. You can check all of them with potential solutions well-discussed on GitHub.

The general assumption is that all code which may lead to issues related to default interface methods implementations is detected by the compiler. In effect, we should get appropriate errors when compiling the source code. That way, programmer can fix all potential conflicts directly when these arise.

What about .NET Framework?

What’s interesting with default interface methods is that it requres changes in the runtime. According to current assumptions, it means that this feature will not work with .NET Framework! Only CoreCLR and Mono stack runtimes are going to receive these new updates.

Summary

As the motivation for introducing into C# default interface methods the language team members mention possibility to interact with some Android and iOS APIs, which already support such feature. They also claim that C# will get the traits programming language feature with default interface methods.

In my opinion this is the most controversial from all C# 8.0 new features. It completely changes something which was obviousness for the developers for years. Probably we’ll see less breaking changes issues when the interfaces are extended, but looking on the list of issues and edge cases it produces… Maybe assuming it already works in a similar way in Java we should just accept it?

Another interesting, .NET-specific aspect is that this feature will not work with .NET Framework. It’s probably the very first moment when the difference in pace between .NET Core and Framework is so explicit.

I’m also very curious about the performance implications of default interface methods. I’ll for sure be following this issue on GitHub to see how it evolves

What do you think? Is it a good idea to introduce default interface methods into C#?

The post C# 8: Default Interface Methods Implementation appeared first on CodeJourney.net.

Let’s see how this tiny feature is supposed to make our life easier

Goal of slicing

The main purpose of introducing slicing into the language is to make working with arrays and strings easier.

Currently, when you want to retrieve a fragment of an array (X elements from the array, located for instance in its middle), you can use LINQ, i.e. combination of Take and Skip methods. You can also create some extension method to provide kind of slicing.

To illustrate the current way, using LINQ to retrieve only 2nd, 3rd and 4th elements of an array looks as follows:

C# community and designers decided it’s not convenient enough, so are now adding to C# 8 indexes and ranges (in order to provide slicing)

Index

C# 8.0 comes along with a new object – System.Index. It’s a structure internally and looks as follows:

What’s interesting here, is that the constructor takes the value of the index and boolean flag fromEnd. Let’s see how we can use it in practice:

While the first printed value is nothing special, as you can see we can now use the hat operator (^) in order to index from the end. The following also works:

It means that the ^ operator is a syntactic sugar for Index. I allowed myself to check the IL produced:

As we suspected – an instance of Index is created, passing 3 as value and true as fromEnd (see the constructor parameters above).

Range

Another concept which uses Indexes is a new structural data type – System.Range:

As you can see, it really uses Indexes. We can even try creating it on our own:

This doesn’t really make extracting data from the arrays better than Skip-Take LINQ, does it?

Fortunately, there’s another friendly C# language element introduced called range expression. It can be written as x..y and used directly for indexing:

This looks much better! Let’s see how C# compiler translated our 2 lines of code by looking at the pseudo-C# IL produced:

Even though we could achieve the same with much less LINQ, C# compiler does a lot of stuff for us, keeping our code simpler to grasp.

Ranges in strings

All these operations apply also to strings:

Ranges in foreach loop

Next interesting usage is in the foreach loop:

Summary

I see these “little” C# 8 indexes and ranges as another helpful feature. It’s less breaking and controversial than nullable reference types, still making us write less C# code in the future.

If you’d like to dig the feature even more, I encourage you to read the discussions about it on GitHub, which I always find very interesting

Developers, what do you think about C# 8 indexes and ranges?

The post C# 8: Slicing with Indexes and Ranges appeared first on CodeJourney.net.

Learn about building C# 8.0

C# 8.0 is going to be the next major release of C# language. It should be released by the same time as .NET Core 3.0.

What I find very interesting is C# language GitHub repository. Among others, you can find there very interesting notes from C# language design meetings If you filter well, you can also list so called “proposals”, which are current candidates for new C#’s version (or sub-versions) features. By clicking here you can list C# 8.0 candidates.

I will publish a separate post regarding each feature which I find particularly interesting

Nullable reference types

First of the C# 8.0 features I’d like to discuss are nullable reference types. It seems it’s going to change the way we write our code, so it’s worth knowing this feature.

A bit of history – NullReferenceException

Consider the following code:

Guess what happens after executing this as a console app? Of course, our favorite NullReferenceException is thrown:

In this case, jsDev.LastName is of course set to null.

NullReferenceException has been a nightmare for thousands of developers (and users) for many years. What if, in the cases like our example, we knew before that in this place our object might be null?

New world – #nullable enable

For that purpose, C# development team is introducing nullable reference types. In essence, it makes reference types (like string) non-nullable! However to not be a tough nut to crack, all issues related to assigning null value to non-nullable reference types are presented as warnings, not errors.

In order to use this feature, you need to enable it. You can do it with a preprocessor directive #nullable enabled. We can do it directly in the source code file. In the future, it should also be possible to enable it on project level.

Notice what happens when we enable it in our example:

We’re still able to compile, but this nice warning is displayed As soon as we initialize LastName property in the constructor, the warning disappears:

If you try to cheat, it still works like a charm :

But hey… what if you actually want null in this particular string? You need to explicitly mark your reference type variable as nullable. You probably recall nullable value types like int?, don’t you (read this post if you don’t remember the difference between value and reference types)? Now you can do the same with non-nullable reference types:

Nonetheless, in such case, the compiler still takes care of us:

The final fix is quite obvious – we need to check for null first:

At this stage all warnings finally disappear. You can find the finished source code here.

Nullable reference types in IL

The only thing I found in the IL code compiled from source code with #nullable enabled directive was NullableAttribute applied to properties:

It seems that nullable reference types are implemented by applying this attribute to variables, which is only used by the compiler (runtime is not affected).

Summary

I’m really excited about nullable reference types in C# 8. I personally feel that it even introduces some clarity in the language – we’ll have explicit declarations for nullable value and reference types. However, in more complex scenarios it may bring some confusion in regards to reference types and using “?” character (like generics or collections – see Jon Skeet’s post for more details). For sure it’s a significant step towards eliminating issues with exceptions caused by null references.

What do you think about nullable reference types? Is it a good direction in which C# language is going? Share your thoughts in the comments!

The post C# 8: Nullable Reference Types appeared first on CodeJourney.net.

I didn’t know what to expect from this event, as it was much smaller than other conferences I used to attend and actually organized by 3 .NET geeks (more about them later ).

In today’s post I’d like to share with you my feelings about the event.  I’d also like to smuggle some topics that were covered during the sessions, so you can stay up-to-date with .NET performance world’s trends and dig into them yourself.

Sessions

There was only a single room in which presentations took place. For me it’s a plus, at least there’s no problem with choosing which talk to attend

Even though the conference was held in Warsaw, Poland, all talks (and generally the whole conference) were given in English. There were 7 sessions in total, prepared by 8 – both Polish and international – speakers.

Szymon Kulec – Born to perform – incorporate .NET Core performance

In the opening talk, Szymon started with demystifying performance aspects of .NET Core. We went through the topics like pinning and pooling, Span<T> and Memory<T>.  We’ve also seen some usage of Unsafe.As for “unsafe” types casting.

Generally, the talk was very well-organized. Speaker used a lot of interesting analogies in his slides, which made the presentation very interesting. Great start!

Alexandre Mutel – Behind the burst compiler, compiling .NET IL to highly optimized native code using LLVM

Alexandre took as for a bit different journey – he talked about Burst, which is a Unity’s compiler. It transforms IL into highly-optimized native code with the help of LLVM. It was a really interesting talk, which showed us how performance can be boosted even more, which brings much better experience e.g. in games developed using Unity. Alex also said few words about RyuJIT compiler, which currently fully operates .NET Core. 

The talk was very motivating. Looking on the amount of great job the guys at Unity are doing with Burst… was nice and interesting to hear that

Konrad Kokosa – The history of .NET GC customization – from (almost) nothing to (almost) everything

The last talk before lunch break was given by Konrad Kokosa, the author of Pro .NET Memory Management.  Konrad’s talk was – as the name tells us – about customizing .NET’s Garbage Collector. I’ve already mentioned in this post that GC can work in several modes, but this presentation showed me that there are many more possibilities for tweaking it. Except of going through all different GC modes, like workstations/server/(non)concurrent GCs, the speaker told us what are latency modes and VM hoarding.

However, what’s probably the most interesting from Konrad’s talk is that he’s been developing his own, custom GC implementation! It’s called ZeroGC and is available on GitHub. Its main goal is to provide the GC implementation which does nothing, except of allowing to allocate the memory. Very interesting, especially if you’d like to know what’s necessary to totally change GC implementation in .NET Core 2.0+ yourself.

The session was very good, I felt that Konrad is really into .NET performance topics. Which is not surprising

Łukasz Pyrzyk – Daily Performance Fuckups

First after-lunch talk was given by Łukasz, who served us with a bunch of .NET performance sins (or fuckups, as you prefer ) present in .NET developers’ life.  Among others, we’ve seen some interesting case-study based on Azure Cosmos DB and one of the issues the speaker and his team met while deploying the system based on it on production.

The talk was engaging and really “close to our everyday life”. It was practical and showed that even if we think we’re doing everything correctly, following the documentation and best practices, we may still meet a lot of problems no one would ever think of.   

Adam Sitnik and Andrey Akinshin – Powerful benchmarking in .NET

These two crazy guys – Adam and Andrey, decided to give a talk lead by both of them. The session was held in a form of conversation – one of the guys was asking the question, while the other was answering it. Quite interesting form, especially that both of them are really passionate about what they’re talking about, so it’s good they chose such clear organization of their talk

Guys told us how we should all measure the performance of our applications – of course using Benchmark.NET library. Honestly, it has really become a benchmarking standard in .NET ecosystem recently, especially that it’s supported by .NET Foundation.

The goal of Benchmark.NET is to allow the developers measure the performance (execution time and many more…) without taking care of creating proper sandbox environment or choosing correct number of iterations – the library does it all for us. It’s easy to start using it, however it offers a lot of possibilities. You can find more information on its GitHub repository.  Definitely worth knowing and checking.

Shay Rojansky – From zero to hero – the Npgsql optimization story

In one before the last technical presentation of the day, Shay presented behind-the-scenes of Npgsql, an open-source ADO.NET provider for PostgreSQL. The speaker also explained what is a lock-free programming and how to do it with connection pooling techniques.

The talk was information-rich and compelling. Shay is a charismatic and engaged speaker, it was very nice and motivating listening to his passionate talk.

Jarosław Pałka – We are all doomed, which is why, what we do can not be called programming

I didn’t know Jarosław before, but he’s a really cool guy – even though he comes from Java world!

Jarek’s talk was mostly focused on virtual machines, how they work and why we actually use them. The speaker is also very charismatic and engaging the audience. He explained basic VMs concepts based on his own EgoVM virtual machine. Slides from the talk (not sure if these are exactly the same ones, but it seems so) can be found here.

I enjoyed the talk and the speaker itself, it was a perfect end of the performance geeks day

Venue and organization

Last but not least, few words on the conference venue and organization in general. The Airport Hotel Okęcie, in which the Dotnetos Conference took place, was a very good choice. The event was rather small, compared to conferences like .NET Developer Days and that’s what made it really cool and cosy. The food was very good, both lunch and snacks/cakes available in the venue’s hall.

Another great idea was the form of voting for the talks by putting green, yellow or red cards into a box after each session. Easy, but effective – I saw a lot of people voting.

In the conference starter pack we got a linen bag and shirt with Dotnetos logo. Of course, the organizers couldn’t miss the Dotnetos tabasco sauce which we also received

Summary

Summing up, the Dotnetos Conference 2018 was a great event, with only high-quality speakers. I can’t even choose the best session – I enjoyed all of them.

Huge thank you to the organizers – Łukasz, Konrad and Szymon. Great job guys, we’re waiting for more!

If you’re interested in internals of .NET, I also invite you to check out my .NET Internals series

The post Dotnetos Conference 2018 – .NET Performance World appeared first on CodeJourney.net.