DEV Community: Tom Smykowski

Angular Silently Released AI Guidelines

Tom Smykowski — Mon, 09 Jun 2025 17:25:55 +0000

The new guidelines show how you can use Google AI services in your Angular app without trouble, protecting your APIs and doing multimodal queries with ease
I’ve lately discussed how the new versions of Angular make it actually better to vibe coding with this framework than other. But that’s not all. The dedication to support AI is also seen in the Angular documentation.

Just lately it was extended with two pages dedicated to building Angular apps with AI. First is “Get Started”, and second “Using AI for Development”.

Hi, My name is Tom Smykowski, I’m a professional core frontend engineer building scalable MVP frontends and helping creators and teams embrace vibe coding

The first one shows how you can use AI in Angular apps. There is a guide using Genkit, Firebase AI Logic and Gemini API in your apps.

If you don’t know already, Genkit is a Firebase open source library to create full stack apps based on AI, so it’s created by Google. You can easily connect to Gemini, Imagen, OpenAI, Anthropic, Llama, Mistral and Ollama and other with this library.

A vibe coding t-shirt
Firebase AI Logic is a layer to connect to Google models too, and the documentation is quite not clear what is the difference here. One for sure is that Firebase App Check is something you can use with Firebase AI Logic to protect your API interfaces. What’s useful is that the API is multimodal, so you can send prompts and files, whatever you want basically.

In the guide you’ll find examples of simple apps built with AI that showcase how it can be used for practical B2B and B2C applications.

The second guide “Using AI for development” is doing what I mentioned in previous post. It provides LLM guidelines for your favorite model. That page is quite short. But really what to write more other than providing guidelines for the model. It’s all vibe coders really need.

Vibe Coding: How AI Turns Your Ideas Into Real Software

Tom Smykowski — Tue, 20 May 2025 21:04:53 +0000

You’ve probably heard someone say, “You don’t need to be a programmer to build an app anymore.”
That’s not an exaggeration — that’s vibe coding. And whether you’re a complete beginner or a seasoned software engineer, it’s changing how we create.

Let me explain.

When you’ve got an idea — say, opening an ice cream truck — your instinct is to do everything yourself. You’d probably buy the truck, find the equipment, fix it up, handle the paperwork, and drive it too.
Why? Because doing things yourself is usually the cheapest option.

But some things aren’t that easy to DIY — and coding might be one of them.

Maybe you're a designer, a data scientist, a QA tester, or just someone who doesn’t code at all. You still might have a great product idea: an app, a store, a tool, a site. But building it requires development skills — and usually, hiring a developer.

And here’s the reality: developers fall into two categories.
Cheap ones might get something working, but it probably won’t be what you actually wanted — and changes later will cost you.
Good ones will build your vision — but that’ll cost serious money upfront.
And unless you have an investor or savings, that option might not be possible.

So what do you do?

That’s where vibe coding comes in.

What Is Vibe Coding?

Vibe coding is a way to build software by collaborating with an AI.
Instead of writing code manually, you describe what you want in plain language — and the AI generates the code for you.

You’re not writing syntax — you’re writing intent.

You can use tools like Windsurf, Cursor, Codex, or VSCode with Copilot. You open the editor, chat with the AI, and watch as your app starts to take shape. You can say things like:

“Make this button open a modal with a form”
“Create a login page with email/password and Google login”
“Split this component into smaller reusable parts”

The AI understands. It writes the code. You steer the ship.

And here’s the twist: vibe coding isn’t just for people who don’t code.

As a professional developer, I use it every day. Why? Because AI is now smart enough to handle boilerplate, generate test cases, scaffold files, and even help with architecture decisions. That lets me focus on what matters most — writing quality features, designing scalable systems, improving UX, and shipping faster.

It’s not about giving up control — it’s about amplifying your speed and precision.

I don’t care if I typed the code or the AI did. I care that it works, follows best practices, and solves the problem. With vibe coding, I get to that outcome faster — with more energy to spend on the hard stuff.

And if you don’t code at all? This is your golden moment.
You don’t need a computer science degree to build. You just need to know what you want — and vibe coding helps turn that into software.

To summarize:

Vibe coding is the process of chatting with AI that generates software for you. Whether you’re a complete beginner or a senior engineer — it’s real, it’s powerful, and it’s changing how we build.

If you don’t know where to start: subscribe to my vibe coding newsletter, where I share actionable tips every week for free so you can manage AI to write perfect code.

While we’re at it, check out also my latest 459-page e-book called Vibe Coding Bible that help people like you become frontiers of the new way of building apps!

And if you’re a founder, check out also my latest e-book: https://summonthejson.com/products/ai-for-founders-100-powerful-tools-to-start-and-scale-your-startup-e-book-pdf-epub, where I share 100 AI tools for people like you to help in every step of the round to turn your idea into reality.

Why Angular Crushes React When It Comes to Scaling Enterprise Apps

Tom Smykowski — Wed, 19 Mar 2025 08:20:51 +0000

Picking the right framework is key to growing your app without headaches. The wrong choice can lead to messy code, higher costs, and constant rework. Angular is built to handle growth, making it easier to go from a small project to a large, scalable product. If you want to avoid common scaling problems, this article is for you.
One of the major decisions a startup or company has to make is deciding which set of technologies to use to build an app. There are many ways to approach this, and one of the biggest choices is selecting the right framework.

Hi! My name is Tom Smykowski, and I’m a senior software engineer. Throughout my career, I’ve worked on both startups and large-scale enterprise applications serving millions of users and developed by hundreds of frontend engineers. This experience has given me a unique perspective on what works — and what doesn’t — when it comes to building scalable applications.

Currently, we have several options, such as frameworks based on the React library, like Next.js; Vue and its ecosystem; and Angular, among others.

Today, I’ll focus on what makes Angular great if you want to scale your app. By scaling, I mean preparing an app in a way that allows it to smoothly transition from an MVP to a fully-fledged product and from a small team of 2–3 frontend developers to a large-scale operation with 30–50 frontend developers spread across multiple squads, developing and maintaining the app at scale.

If your service or product is based on digital services, this is an inevitable future. As your business grows, your app must keep up with market demand and serve both customer and user needs. Early on, it’s crucial to set up your app to be flexible enough to accommodate pivots on the path to unicorn status — without hitting the dead end of skyrocketing legacy development costs.

Angular is a great choice for building scalable apps, and today, I’ll share some practical insights into why.

1. If You Want Your Business to Grow, Choose a Framework That Scales With It

When evaluating tools for building an application, we can categorize them based on their complexity. For example, you can write fully functional apps using only JavaScript, without any framework or library. However, this means you must handle everything that frameworks and libraries typically provide. As a result, the complexity of such an application will be the highest. Developers will need to solve problems that have already been addressed by existing tools, forcing them to work at a low level rather than focusing on business logic and user experience. This makes development more expensive and error-prone. On the positive side, developers will have full control over every aspect of the application.

On the other end of the spectrum, you can choose tools with very low complexity, such as no-code platforms. This approach can reduce development costs because no-code tools enable app creation with little to no coding. However, the trade-off is a lack of flexibility — if a tool doesn’t support a feature, you may simply be unable to implement it. This inherent limitation makes low-complexity tools unsuitable for scalable, evolving applications.

Frameworks and Libraries on the Complexity Scale

Libraries and frameworks also fit on this complexity scale, and choosing the right one depends on the level of complexity your project requires.

React is a library, meaning it provides a low-level solution for building UI components. To create a framework-like structure with React, you either need to use Next.js alongside additional libraries or manually assemble your own set of tools. Each React-based setup is unique — it varies from company to company and team to team. The flexibility of this approach allows switching out tools while keeping the core intact, but it also comes with a downside: developers must manage low-level concerns, ensuring that all loosely coupled dependencies work together.
Angular, on the other hand, is a framework, meaning it abstracts away low-level concerns so developers can work at a higher level of abstraction. In the past, Angular had significant complexity due to over-engineered modules, cumbersome reactivity, and a tedious templating model. However, recent improvements — such as standalone components, new template authoring, and signals — have repositioned Angular as a low-operational-complexity tool with a low entry barrier.

Why Angular Is Better for Scaling

Learning Angular is now easier than mastering the various React-based frameworks. Since Angular follows a standardized approach, developers can seamlessly switch between different Angular projects and sections of an app while maintaining productivity.

React works well for small, simple applications and MVPs, where flexibility is an advantage. However, as an app scales, the challenges of React’s low-level approach start to dominate, leading to higher development costs.

Angular, by contrast, supports MVP development while also providing the tools needed to pivot and scale without requiring expensive architectural overhauls. This makes Angular a better choice for building scalable applications from the start.

2. Scaling From One Developer to One Hundred

For scalable apps, it’s inevitable that the businesses offering them will grow. You can start a SaaS service to manage transportation by using AI to write a simple rail transport and scheduling application. If you gain expertise in this process and find a niche, your MVP app can successfully enter the market.

What many technical founders miss is that to scale the business further, they’ll need to expand the range of problems they solve for their customers. For example, people transporting cargo likely also use ship transportation and may need solutions for packaging and sorting. As these needs grow, companies using your app will want to integrate as many of their processes as possible into it to streamline operations. This also means handling users with different roles and permissions.

Suddenly, you may find yourself buried under customer requests, inevitably leading to hiring more developers and organizing their work to handle all business-critical features efficiently.

Organizing Teams and Code for Scalability

A great way to structure both development teams and code is around specific types of operations, for example:

Ship Operations Team
Cargo Control Team
Rail Operations Team
Packing & Sorting Team

Each of these teams is responsible for a specific vertical of the operation and oversees the development of app features related to that part of the business. In practice, each subsystem can exist within the application under different menu sections.

From a technical perspective, this means that feature elements, such as components, data handling, and helper utilities, should be grouped together in the codebase. This clear separation of ownership ensures maintainability and scalability.

Both React and Angular allow structuring feature files into functional directories. However, Angular previously relied on ngModules to organize features, a parallel structure that is now being phased out in favor of standalone components. This shift simplifies code reorganization, making it easier to reflect the organizational structure of a company within the codebase.

Additionally, Angular’s built-in lazy loading, improved tree shaking in the latest versions, and signal-based performance optimizations now make Angular apps feel significantly faster and more responsive, even on slow internet connections. This is a major improvement compared to the older days of Angular.

3. Performance Shouldn’t Sacrifice User Experience

In life, as in programming, when you try to handle too many things at once, none of them is done properly. React is a great example of this. It offers low-level development, which can enable edge performance. However, when we look at React apps in practice, we see some drawbacks.

When developers have to manage low-level concerns, they have less time to focus on the user experience. Conversely, when they prioritize user experience, they have less time for performance optimizations. The result? React apps that are either difficult to use due to UI quirks, slow, or — most often — both.

Key Business Questions When Scaling

From a business perspective, the most important questions are:

Can we provide this feature?
How much will it cost?
When will it be ready?
Will it work properly?

In reality, businesses operate under budget and time constraints, which means that feature development must make sense from a business perspective. No matter what technology stack you choose, to stay competitive, you need to:

Deliver features quickly
Keep development costs low
Ensure features work properly
The Trade-Offs in Development

These constraints often force developers to make sacrifices, such as:

Limiting the scope of a feature
Delaying accessibility and performance improvements
Leaving UI quirks for future fixes
Ultimately, you want to choose a toolset that minimizes risks in all these areas, allowing you to deliver features on time and within budget.

How Angular Reduces Development Risks

A great example of Angular’s approach to reducing complexity is memory leak prevention. A memory leak occurs when an app fails to release memory after objects are no longer needed, gradually slowing down performance until the app becomes unusable or crashes.

With Signals, Angular now automatically unsubscribes from Observables, eliminating a common source of memory leaks. Previously, developers had to manually manage subscriptions, which was often overlooked. The less developers need to worry about these low-level concerns, the more time they have to focus on delivering features, which is their core job.

Angular, as a framework, is designed to handle these complexities so that developers can concentrate on building great products, not fighting unnecessary technical debt.

Summary

Choosing the right framework is crucial for long-term growth. While React offers flexibility, it requires managing low-level complexities that can slow development as teams scale. Angular, on the other hand, standardizes architecture, making it easier for developers to collaborate and maintain large applications.

With built-in performance optimizations, automatic memory management, and structured scalability, Angular reduces development risks while allowing businesses to deliver features quickly and efficiently. If you’re building for scale, Angular provides the stability and flexibility needed to grow without technical debt slowing you down.

Scaling your app shouldn’t mean chaos, rising costs, or endless refactoring. Want to build an Angular app that scales smoothly from startup to enterprise? Grab my free checklist now and ensure your app is built for growth, efficiency, and long-term success!

Scalability Essentials: Angular Accessibility Has Bigger Impact Than You Think

Tom Smykowski — Sat, 15 Mar 2025 21:47:18 +0000

Years ago I thought accessibility was for 0.1% of people. Working on apps serving millions of users taught me it’s about way more people, who have to be included when building scalable Angular apps
One of the main goals of us, frontend software engineers, is to make sure the apps we build are accessible to as many people as possible. There are many ways to ensure that, for example having great designs, but also being really focused on how the app works. Testing it in multiple browsers, on multiple resolution, screen orientations and so on.

But the term “accessibility” isn’t really about it, but, as Wikipedia says:

Web accessibility, or eAccessibility,[1] is the inclusive practice of ensuring there are no barriers that prevent interaction with, or access to, websites on the World Wide Web by people with physical disabilities, situational disabilities, and socio-economic restrictions on bandwidth and speed. When sites are correctly designed, developed and edited, more users have equal access to information and functionality. (source)

What we can recognize as the user oriented needs for web accessibility can be grouped into multiple categories:

visual impairment
motor / mobility
auditory
seizures
cognitive and intellectual

And we tend to think these issues only affect some minor group. So we apply WCAG rules not always as part of the general process. It’s rather something that is either taken care of to some extend during the whole design and development process, or at some point as a separate task.

By the way, my name is Tom Smykowski, I’m an expert in building scalable, enterprise Angular applications and in this series I’ll be teaching you how to do it!

Approaches to accessibility depend on many factors, including legal requirements. But from the people perspective, what can be surprising, that actually accessibility isn’t about a narrow group of people.

Just to five some examples. Around 8% of men have what is called congenital red–green color blindness. It means that they can’t to various extend to differentiate some pairs of colors:

cyan and gray
yellow and neon green
black and red
red and green

It seems to not affect UI development, until you have a list of alerts and notifications. When alert and notification icons are similar and small, people won’t be able to recognize what is what leading to problems or to considerable inconvenience that will drive them away from your app.

And we’re not talking about some minor group. It’s 8% of men. An inaccessible app in that matter can be a blocker for 8% of potential users. If someone came and said, he can increase adoption by around 8%, he would be called a charlatan, but here accessibility itself can do it without any impact on business and marketing processes if initially the app isn’t accessible in that matter.

Another set of disorders that affects if people can use apps is motor difficulties. For example essential tremor. It’s a motor neurological disorder causing involuntary, rhythmic shaking of hands that affects almost 1% of global population.

People with essential tremor, but also other motor disorders find many difficulties in life, also in the area of digital life where apps that should help them, not always do it. Too small buttons, located too close to each other are only a tip of an iceberg of thigs that can lock out people with disabilities from these areas from your application.

Moving fast forward to intellectual and cognitive conditions, just for selective example, we have around 1% of people affected by intellectual disabilities, and separately and not connected, 10% of global population affected by autism spectrum.

Complex and overloaded interfaces, ambiguous icons, wording, non consistent navigation, jargon or complex language, no clear feedback, poor readability are just some of elements that affect negatively people with intellectual and cognitive conditions.

Again, a quite large proportion of people globally that will find it hard to use your app if it’s not accessible. What’s interesting, especially for MVP driven startups this is essential, because the app shouldn’t only do the one thing that people want, it should also allow them to do it.

As you can see, accessibility isn’t only for few people, it’s for a quite large proportion of all people. Around one of three people has a condition that makes using apps difficult.

Inaccessible app isn’t just an inconvenience and in highly competitive market it’s a deal-breaker. No one will use an app if they can go to competition that allows them to do just what they need to do despite their various conditions.

In terms of scalable Angular apps, it means we should focus on accessibility and treat it as essential process of design and development. I’d say even more, we should sacrifice other design goals if they lower accessibility, because there’s no sense in building pretty things that people can’t use.

The goal of architecting scalable Angular apps is to build ones that are widely used, and prepared for global usage horizontally and vertically. In the process terms a good design system and component library are places where accessibility can be provided organisation-wide.

But it also requires training and including accessibility in all processes affecting user interface, from requirement phase, through design to implementation and maintained, because everyone involved in these processes has to be aligned to reach for the same goal.

That way we don’t build accessibility debt. Compared to technical debt, accessibility debt affects our users every day. Way more people than we think.

I’ve prepared a free checklist how to make your Angular app scalable and ready for enterprise demand. If you’re interested, you can get this checklist for free here.

If you have any questions, ask these in the comment section!

Signals Are A Game Change For Scalable Angular Apps That Shouldn’t Memory-Leak

Tom Smykowski — Fri, 14 Mar 2025 11:07:00 +0000

Signals in Angular are quite new concept, so not everyone is already using them, or are familiar with them. Creating a signal is quite easy:

const count = signal(0);
But what it really is? Well, it’s a construct that plays very well with reactive programming and Angular templates. Because so far Angular had to do a lot of things to recognize what changes and when to update templates. Just to say zone.js is a really huge part of Angular and it tries to tap into natural things like setTimeout functions to spy on stuff coders do to update things smoothly.

By the way, my name is Tom Smykowski, I’m an expert in building scalable, enterprise Angular applications and in this series I’ll be teaching you how to do it!

The OnPush method changed it, because with this strategy Angular reacts only to input changes and events. However, it’s not a perfect solution and having to choose between ngOnChanges, get/setters for inputs and Observables and Subjects isn’t really fun. All of these approaches come with more or less boilerplate that only obfuscates the feature oriented components.

What’s even more important when working with asynchronisity in Angular is that it’s really easy to introduce memory leaks. All you have to do is not unsubscribe from a Subject (or BehaviourSubject etc.) or event based observables (like fromEvent) for them to leave not-quite rent free forever in the device memory. It’s considerably the biggest drawback of these approaches.

Not a lot is said about it, but Angular Signals are also solution to this problem. Specifically, as we can read in Angular documentation:

When you create an effect, it is automatically destroyed when its enclosing context is destroyed. This means that effects created within components are destroyed when the component is destroyed. The same goes for effects within directives, services, etc.

So we don’t have to worry about this. Context knows about signals, and destroys them properly. So if you have a signal in your service or component, you don’t have to worry about a memory leak.

Moreover, and this is really impressive, is how signals handle Observables and RxJS. No doubt, signals, as for today, aren’t able to take over all the good RxJS gives, however in some cases we may not need RxJS when working with signals.

But what it means is that we could still be at risk of creating memory leaks when integrating signals and RxJS. The good news is that the unique construction of signals addresses this problem:

The toSignal function allows you to turn an Observable to signal:

import { Component } from '@angular/core';
import { AsyncPipe } from '@angular/common';
import { interval } from 'rxjs';
import { toSignal } from '@angular/core/rxjs-interop';
@Component({
template: {{ counter() }},
})
export class Ticker {
counterObservable = interval(1000);
// Get a Signal representing the counterObservable's value.
counter = toSignal(this.counterObservable, {initialValue: 0});
}
As we can see in this example provided by Angular documentation, counter becomes a signal tracking counterObservable. Because a standard observable doesn’t guarantee to emit a value, we set an initialValue, otherwise it would be undefined.

This is however not the important part of the story, because the important one is that toSignal takes care of unsubscribing from the observable:

The subscription created by toSignal automatically unsubscribes from the given Observable when the component or service which calls toSignal is destroyed.

Basically meaning that it acts as memory leak sanitizer, making sure that observables we use in components and services won’t create memory leaks because unsubscription is taken care automatically of.

It’s a considerable advantage of signals contributing to solving the major cause of lags of Angular apps. Since toSignal unsubscribes automatically when service or component is destroyed, there’s no risk for human error.

What’s great. Of course there are cases where memory leaks can still happen, and for that cases we still can clear resources manually with manualCleanup that is called when the signal would normally do house chores.

From the perspective of building scalable Angular apps this, and other reasons, I’ll write in following articles, signals are great to preserve resources, increase responsiveness of Angular apps and save resources, especially in apps that by themselves use a lot of these.

The streamlined handling of reactivity Angular 16 introduced with gradual feature build-up (like signal-based inputs in Angular 19) make them a great fit for scalable apps due to lower maintenance costs, lower risk of memory leaks and better overall performance. I recommend to gradually rewrite your app to signals if you want to scale it smoothly.

I’ve prepared a free checklist how to make your Angular app scalable and ready for enterprise demand. If you’re interested, you can get this checklist for free here: https://tomasz-smykowski.com/scalable-angular

If you have any questions, ask these in the comment section!

Webdevs Are Melting 🫠 Typescript Will Be 10x Faster. Thanks To Go Language

Tom Smykowski — Tue, 11 Mar 2025 18:26:03 +0000

TypeScript compiler and tools show 10x speed improvement when rewritten to Go. Process to go fully live is ongoing

There’s no other thing on earth that brings a smile to soon-cease-to-exist (apparently) developers as faster tools.

In this case the tool is Typescript, a strongly typed Javascript superset and compiler that makes web development less frustrating.

Anders Hejlsberg decided to sweeten this day today for many people by announcing a super secret project called Corsa, just like Opel Corsa. And as the car is fast, as Typescript will be.

But we don’t talk about any neatly optimised function, the Typescript team decided to go full Gopher and rewrite compiler and TypeScript tools from Javascript to Go language.

The little forgotten language that let’s remember, is in the elite of the new wave alongside with Rust, was chosen to pump Typescript performance.

So far there is a public repo with what is done so far and some tests, while the final version should land in middle of the year 2025.

Opening VSCode codebase in VSCode (not a typo) takes 10 times less. Not 77s, but 7 seconds. We are talking here about a codebase with 1,5 million lines of code!

The news is really exciting because it will boost all tools and frameworks that use Typescript, also pipelines.

Among all the things that dropped today, TypeScript time is the best.

I’ve prepared a free checklist how to make your Angular app scalable and ready for enterprise demand. If you’re interested, you can get this checklist for free here.

source

Switch Now To Angular Standalone Components

Tom Smykowski — Mon, 10 Mar 2025 19:18:00 +0000

Building scalable, enterprise Angular apps comes with some challenges, one of which is to organize project in a way, that something maintained by two-three developers will be good to be developed by several teams like this.

So the organisation of the project is really important. Especially because an enterprise app can consist of anything between 100 and 500 components and same amount of services.

By the way, my name is Tom Smykowski, I’m an expert in building scalable, enterprise applications and in this series I’ll be teaching you how to do it!

Before standalone components were introduced, you had to put every component, directive and pipe into a module. Here’s an example of a module:

@NgModule({ declarations: [AppComponent, HeaderComponent], imports: [CommonModule, FormsModule], providers: [SomeService], bootstrap: [AppComponent] }) export class AppModule {}

There were several problems with this approach. First of all, modules aren’t always necessary. Other libraries like React doesn’t require this construct. For a reason, it increases complexity, increases risk of circular dependencies, makes the codebase harder to understand (you have to figure out what module exports your component, especially difficult when working with 3rd party libraries), lazy loading was a bit complex, and well… there was really a nice pattern to use them.

If you put too much in a module, it gets bloated and your app suffers on performance, because Angular is unable to tree-shake them properly. If you create a module for every component… what is the best option… what’s the point of modules at all?

These issues led to creation of standalone elements in Angular. Now you import a component, service, or a pipe directly where you use it, from where it’s defined:

`import { Component } from '@angular/core';
import { CommonModule } from '@angular/common';
import { MeasurementCardComponent } from './measurement-card.component';
import { UnitConverterPipe } from './unit-converter.pipe';
import { StatusDirective } from './status.directive';

@Component({
selector: 'app-factory-dashboard',
...
imports: [
// HERE
CommonModule,
MeasurementCardComponent,
UnitConverterPipe,
StatusDirective
]
})
export class FactoryDashboardComponent {
...
}`

As you can see, it’s easier to figure out and find dependencies of the component using standalone entities.

When you are not there yet with your codebase to use standalone entities, you have to know that in Angular 19 components are standalone by default. You don’t have to add standalone: true to the decorator:

@Component({ selector: 'app-factory-dashboard', standalone: true, ... })

You can also use the schematic to automatically switch to standalone:

ng generate @angular/core:standalone

It will also change other elements like bootstrapping and routing. So a lot of things will be taken care of automatically.

In my experience the schematics works quite good. If you use some special things in your application, you may need to do some manual adjustments. But as long as you sticked to Angular standards, it should go smoothly.

To summarize by updating and switching to standalone components, your app complexity will drop, maintainability increase, build size will drop and initial load time drop. All of these contribute strongly to building scalable Angular app.

In my experience of working on Angular apps serving millions of users, standalone components are mature, and serving purpose they were designed for. So, I encourage you to switch to standalone entities.

I’ve prepared a free checklist how to make your Angular app scalable and ready for enterprise demand. If you’re interested, you can get this checklist for free here.

If you have any questions, ask these in the comment section!

Enhance Your Code: CodiumAI’s Automated Analysis and Suggestions for Python and JavaScript

Tom Smykowski — Tue, 13 Jun 2023 14:09:45 +0000

Writing code tests plays a vital role in software development, guaranteeing high-quality code, early bug detection, and enhanced maintainability. Yet, this process often becomes a time-consuming and monotonous endeavor.

Developers frequently find themselves allocating considerable time to writing tests, diverting their attention from actual development. Fortunately, the progress in artificial intelligence (AI) has opened doors to automated test generation, presenting developers with an innovative method for creating code tests. One such tool is CodiumAI, which allows you to automatically generate tests for your code.

With CodiumAI, you receive meaningful and straightforward test suggestions directly within your integrated development environment (IDE), enabling you to write better code. Let’s see how we can use CodiumAI on VSCode and PyCharm.

I will be keeping it simple and will only focus on how CodiumAI can be used to do an analysis of the code and also get suggestions.

How to Use CodiumAI to Generate Tests for Python

Let’s take a simple Python code to better understand how code analysis could be done using CodiumAI. The following function, ‘largest_prime_factor’ takes a number and tells the largest prime factor for that number.

For some people, this code could be difficult to understand. Along with that, this code is also not well-optimized. Let’s check out the analysis of the CodiumAI regarding our Python code.

Click on the ‘Generate tests for the below function’, to pop up the CodiumAI window. Once the CodiumAI tabs show up, click on the ‘Code Analysis’ tab.

As the name suggests, the analysis tab provides a detailed analysis of the code. This covers objectives, inputs, flow, outputs, and a few additional aspects. Almost anyone can easily understand the code by just simply going through the analysis. This makes it easier for other programmers to understand the code and also contribute to it.

You can also improve your code with AI-generated suggestions. For suggestions, click on the ‘Code Suggestions’ tab to get suggestions from the CodiumAI.

Under the ‘Code Suggestions’ tab, you will see multiple suggestions. Each suggestion contains two things, first the actual suggestion, and second, how your code will be affected by following the suggestion.

Following are the few suggestions given by CodiumAI regarding our Python code.

To apply the suggestion, just click on the checkbox on the top left of each suggestion. After checking the box, click on the ‘Prepare Code Changes’ button at the bottom right of the window. You can also select all the suggestions by clicking on ‘Select All’, which is present at the bottom left of the window.

Once you click on ‘Prepare Code Changes’ you will see a new window with the previous code along with the suggested changes for a better comparison. You can also see the list of suggestions that are being applied to the code.

After that click on ‘Apply to my Code’ to apply the changes. Right after clicking, your code will magically change into a well-optimized, functional code. Just a few clicks, it’s that simple.

How to Use CodiumAI to Generate Tests for JavaScript

We have seen how we can get detailed suggestions for our Python code. Now let’s see how we can do the same with JavaScript.

I have taken an easy and basic example of a Fibonacci series generator in JavaScript. The following function generates n number of terms in Fibonacci Series.

Is our code perfect? I mean it does the job but is it really perfect? Let’s see what CodiumAI thinks about this.

Click on the ‘Generate tests for the below function’, to pop up the CoidumAI window. Once the CodiumAI tabs show up, click on the ‘Code Analysis’ tab.

Once you click on it, a detailed analysis of the code is displayed. The analysis includes objectives, inputs, flow, outputs, and some additional aspects. As you can see in the screenshot, this is a pretty detailed analysis of such a small function that we wrote. Anyone can understand the code immediately by just going through the analysis. This might not look much helpful in this example that we are using, but this is very helpful once you are writing complex code. This makes it easier for others to understand your code.

This is the analysis part. The best thing is that we can get code suggestions for JavaScript too.

Click on the ‘Code Suggestions’ tab and you will be presented with some suggestions. The process is similar to what we followed for Python.

Following are the few suggestions given by CodiumAI regarding our JavaScript code.

After that click on ‘Apply to my Code’ to apply the changes. This will convert your code into a well-optimized, readable code. I bet you haven’t seen an easier method of code refactoring than this!

As you can see CodiumAI is quite nice if it comes to code analysis and suggestions too. I found this feature by accident, and already using it often. Do you use any AI tools to improve your coding? Let me know about it, and what do you think about CodiumAI!

Subscribe for more coding articles and tools!

🐍 🎂 Happy Birthday Python! You 32yo Bada**!

Tom Smykowski — Sun, 19 Feb 2023 20:48:58 +0000

Python is with us for 32 years. Check out some interesting facts, stories and a birthday poem for Python’s birthday!

🐣 21 Messages Of The Revalation

32 years ago, on 20th February 1991 Python made it’s first appearance. Let’s look how far the programming language created Guido van Rossum went.

The first Python source code was published by Guido on the very day on the Usenet alt.sources newsgroup.

For the younger audience Usenet is a precursor of Telegram. It’s free and decentralized like Mastodon, and allows people to exchange text messages on thousands of newsgroups.

The alt.sources is one of such newsgroups specifically created to publish interesting snippets of code. Guido’s post was one of hundreds. I wonder if Usenet readers noticed at that time, that very post will mark an important day in the history of programming and technology.

This is how Guido described his creation:

This is Python, an extensible interpreted programming language that Xcombines remarkable power with very clear syntax.

Python can be used instead of shell, Awk or Perl scripts, to write prototypes of real applications, or as an extension language of large systems, you name it.

The announcement of Python 0.9.1 was split into 21 Usenet messages and released after two years since Guido started to develop it.

Now, it’s everywhere. Let’s look at some notable accomplishments of the PY!

🔭 Python Gives Us AI, Car Autpilots And Earliest Photos Of The Universe

To say Python is everywhere is too little. GPT-2, and most likely GPT-3 is written in Python. You know, the AI chatbot everyone is talking about.

Also, the OpenPilot relies heavily on Python. It is an open source autopilot for a range of cars.

NASA relies on Python apps to process and handle data from James Webb telescope giving us the unique chance to see how the Universe looked like just after The Big Bang.

Python is used for cloud computing, data science, backend services, education, and everything that needs code.

The TIOBE ranking indicates that Python is the most popular language since around 2021, and from the top languages, it shares the rapid growth only with C++.

To sum it up, 32 birthday is a moment when we can recognize that Python became the most important programming language on Earth and beyond.

💡 Python Is An Impossible Invention

You may think that Python is a new invention, but when we will put it on the historical timeline it almost feels like it was made in ancient times.

Digital cameras had 2MB of memory, you had to use a cassette player if you wanted to listen to the music on the go, to have a phone call you had to find a phone booth, and the major sources of information were radio, television and newspapers.

The world changed rapidly during these 32 years not only in terms of technology, but also our lives changed:

We have increased photovoltaic energy production from almost zero to around 20% of world’s consumption
The life expectancy increased by 9 years ( from 64 to 73 years )
Poverty decreased by 23 percent points

It means that in 1991 there was impossible to imagine how the future will look like and that a newly invented programming language will become an important part of it.

Now, Python is everywhere proving the motivation and hard work of Guido and everyone involved during the years into Python development paid off greatly.

We know how Python was born, how popular it is, and the long road it made to the success.

But how people reacted to the new programming language?

🤗 Python Won Because It’s Good For Its Users
Robert A. McLachlan was one of the people who recognized a novelty in the Guido’s approach to programming. As he wrote in January of 1992:

Novel features include strict type checking and source-level debugging of compiled code. Unusual attention has been paid to the compiler’s user interface.

It set Python straight apart from other programming languages at that time. Programming was a mistery job done by few. No one really cared about the user experience of developers.

Check out Python Cheat Sheet Cards I’ve Just Released!

You could use a set of educational purpose language that made your life easier, but later you landed in “real” programming languages that spat ambiguous errors and expected you to know exactly what you are doing.

Python was different because it married the educational and professional coding. The history as we know it prooved it was the right approach.

For years professional developers thought about Python only as an educational language. It gave it time to incubate and attract people who shied away from the voodoo programming and considered a language as a tool to build neural networks, prototypes and data processing systems. A language that helped to get the job done.

But enough with this seriousness. It is a birthday! I’ve prepared some thing special!

🎂 Python Birthday Wishes

It’s 2023 and I am sure that Python will drive the world in the new era of weak AI. Since that said, I asked a Python child to write a birthday poem about its father:

On this day, we celebrate The Python's birthday, so great! It's been around for quite some time And still manages to stay in its prime

It's not a snake, but a coding tool That makes our lives a little less cruel With its syntax, we write with ease And create programs as we please

So let's blow out the candles, with a smile And enjoy this day, in true Python style Happy Birthday to our dear friend May its code never come to an end!

Happy Birthday Python 🎉🎉🎉 thank you Guido for creating Python and congrats to everyone who was / is involved in the development and success of Python!

I am curious how you discovered Python. Do you have any interesting story? Share it in the comment section!

If you like the article clap, like, share, subscribe and follow for more! I am writing about interesting things around Python and software engineering.

-10% On Programming Flashcards

Tom Smykowski — Fri, 25 Nov 2022 17:29:06 +0000

10% on the entire order with the discount code BLACK10. Only on November 25!⏳🎁🖤 #summonthejson

10 Card Games To Learn How To Code

Tom Smykowski — Tue, 09 Aug 2022 07:55:20 +0000

Why is coding so hard?

Tom Smykowski — Mon, 08 Aug 2022 20:40:00 +0000

I have purposefully titled this article in a such way to attract your attention.

If you are here you have to be really on the edge of quitting learning how to code.

And this article won't tell you that you should continue anyways. To push your way through the obstacles and pain.

You should quit right now. It is not an article to motivate you by checking your stubborness.

You really should quit. Here is the thing. Just read further.

Coding is really, really hard. It is hard for everyone. Everyone struggles.

What you feel has nothing to do with you. You are perfectly fine.

But you should quit for real. Our brain is not a muscle. A muscle has to be injured to grow.

Our brain does not work that way. When our brain is injured, it becomes depressed. It becomes ill.

What you feel when ovewhelmed by coding, is your brain telling you it is enough.

Take a break. I know you could go further. But your brain protects itself. It has above reason to do it, but also there is a second reason.

We all think we learn when studying documentation, or writing code.

But it is not true. When we do it, we only gather input for our brain. We gather some questions and answers.

And when we gather to much, our brain says: it is enough. Now you will feel overwhelmed, frustrated.

The brain tells you you should stop. Because it has all the data to actually learn how to code.

It will learn when it will be relaxed. When you sleep. Or when you walk. Or when you meeting your family or friends.

It is a completely background process that you don't have to worry about.

To sum it up. Your brain has all the data. It is fully loaded. Give your brain time to actually do its job.

Relax and enjoy the wonder.

The next time just quit learning earlier.