Join us live for five days of Advent of Code puzzles and five Kotlin livestreams on December 1–5. Solve the puzzles in Kotlin with help from Kotlin team experts and fun community guests, climb the leaderboard, learn new tricks, and have a chance to win some prizes along the way!

Here’s what we have planned for 2025:

• From December 1–5, join daily livestreams with Sebastian Aigner, Kotlin Developer Advocate, and special guests as they explore solutions and share Kotlin tips.
• Hang out with the supportive Kotlin community in Kotlinlang Slack, where people post hints, discuss approaches, and learn from one another.
• Take part in our Kotlin leaderboards for a chance to win exclusive prizes – both for top performers and for active community members who share their Kotlin solutions.

Join us for this JetBrains festive tradition and try solving our Kotlin puzzles this year!

If you enjoy a bit of friendly competition, you can participate in our Kotlin leaderboards on adventofcode.com.

We’ll have exclusive prizes for top performers and extra rewards for randomly selected participants who share their solutions on GitHub using the aoc-2025-in-kotlin topic.

Go to the Leaderboard section of your Advent of Code profile and enter one of the invite codes below:

• Leaderboard 1: 2343137-c975ff11
• Leaderboard 2: 2553918-98f6b5ed
• Leaderboard 3: 2076885-6961eed5

Some handy resources to get you started:

• The Kotlin Advent of Code GitHub template and instructions on how to use it.
• Solutions from previous years in idiomatic Kotlin.

Want to be in the running for exclusive Advent of Code in Kotlin prizes? Here’s what you need to do:

1. Solve at least three Advent of Code 2025 puzzles using Kotlin.
2. Publish your solutions on GitHub in a repository and add the topic aoc-2025-in-kotlin by:

• Opening your repository on GitHub.
• Clicking the gear icon (⚙️) in the top right-hand corner of the repository page.
• Adding aoc-2025-in-kotlin in the Topics field.

3. Make sure we can contact you via your GitHub profile by including an email address, X handle, or Bluesky username.

This helps us discover your solutions and include you in the prize draw!

Join us for Advent of Code!

We’re excited to spend another Advent season solving puzzles, exploring Kotlin, and celebrating clever solutions together.

Happy coding, and see you at Advent of Code in Kotlin!

In workplaces, time is always at a premium. Things move fast, and customers don’t like waiting for new features or fixes. Suitably then, much time and mental power are dedicated to producing high-quality apps that look and feel great. The actual code demands so much attention that sometimes, thinking about how we actually get that code into different environments like testing or production can take a back seat.

Instead of dealing with it, we keep zipping up the new releases and sending them on for deployment, unknowingly perpetuating a cycle where we just repeat the same process, over and over again. All told, we’ll waste hours in this endeavor, and we’ll only wind up ultimately costing reliability.

Here’s what this looks like: I’m just trying to fix a simple issue involving a database connection. I think I’ve got it sorted, so I review my changes, check them in to source control, and my app gets deployed.

And then, the app becomes unresponsive. Fortunately, this is only in a test environment, and twice as fortunately, adopting CI/CD means that rolling back is a breeze. Without it? A much, much bigger mess.

Why skipping out on CI/CD is an amateur mistake

Normally, at my big, important, fancy day job as a Senior Software Developer, there are a bunch of checks and balances that go into the code that I publish. People look at what I write and grimace (They don’t think it’s bad — they’re just thinking — or so they tell me). Then people test it, it gets release approval, and then it finally gets deployed.

But, in my cute little side projects, I don’t have a team of people to do that for me. So I have to do it. Normally, I’m not good at it, so I sometimes publish updates that are wrong or cause issues.

Even in simple deployments, there are multiple steps to follow. Back up the existing database, back up the existing app, stop everything, install the update, upgrade the database, start everything up again, and make sure that everything works correctly. Forget a step, and you’re kind of stuck in an unrecoverable mess.

For example, when deploying the app, how are you getting files from the development server into the hosting environment? Typically, you would build the project, zip it up, send it to the server, and extract it over what was already there. But even that has risks, as wrong zip files are sent, and all too often we wind up with files like “release-deployment-PATCHED-1708-USE-THIS-ONE.zip.tar” as part of our deployments.

Software is notoriously fickle. Extract the wrong version, and it won’t work. Mismatch the database and the software version, and it won’t work. Everything has to be correct; otherwise, the lights turn off, and the ice cream melts.

So what do we do instead?

Starting off strong: Beginning your project with CI/CD

You might see the acronym CI/CD thrown around a lot. For those that don’t know, it means Continuous Integration and Continuous Deployment. And it can sound like a bit of a complex topic — something that maybe you would want to learn about “later” while you focus on coding your app.

But to make the case for it, we have to first explore what deployment looks like without it. You may find parallels in the anecdotes below.

For a long time, I didn’t care about CI/CD or want to learn about it. Not that I didn’t like it. It’s just that the world of software development is huge and varied. If you went down every rabbit hole in the field, you could spend your entire life learning lots and shipping nothing.

I would essentially just implement my fixes or new feature, and then just copy my build directory to the server, and I would be done.

It’s simple. But very soon, the cracks begin to show. I always have to remember not to copy the application configuration file, for instance, as the values in development would differ from those in the test setup.

Sometimes, I would have a problem with a build because of a temporary issue. So I would output my builds to a different location for testing. And then, when the time came to deploy my build to the server, I would have to remember what folder to deploy.

In my day job as a developer (admittedly close to a decade ago – please don’t think this is a recent example ), this would rapidly become worse when deployment time came around. I would produce a build, compress the folders, and send the package in for deployment. At the same time, I would produce a 500-page essay on how to deploy the thing. I would put the files and the instructions together and submit them for deployment.

It’s almost impressive just how many ways we found to mess this up. Routinely, I would send the wrong files. At this point, you might pause and think, “wait, who wrote this article?”. And LinkedIn would tell you that I’m a Senior Developer.

But (and let me restate, this is some time ago!) built files don’t do anything. You build them and they sit there. They only blow up once they are copied somewhere and executed. You only have build-time failures and runtime failures. There are no files-sitting-on-the-disk failures. They don’t exist.

So I would only know that what I had submitted was bunk when the deployment team would come back to me and tell me that I had submitted rubbish.

The majority of the time, I’d submit the right files (having learnt from prior experience). And then the deployment team would deploy the wrong version, read the documentation wrong, or find some other way to flub the deployment.

I probably spent more time trying to solve the human errors than I did the actual program errors. And when you’re trying to fix problems, you’re not moving the solution forward.

Why is CI/CD important?

You already use source control. Well, I mean, I hope you do. If you don’t, then you should learn about that first, definitely. But you’re likely already submitting changes and pushing them to something like GitHub/Azure DevOps/BitBucket/etc. When you do that, each commit winds up with an individual “commit hash”. It’s the thumbprint of that particular check-in.

For these examples, we’ll use GitHub to demonstrate, but other providers should be more or less the same. Also of note: there are many more evolved/proper ways to achieve this. But again, you have to strike a balance. If you get too engrossed in how this works, you’ll be amazing at deployment but will have no time to actually develop an app that needs deploying . Onwards!:

Okay, so that’s fairly unremarkable. But within my repository, there are actions that run every time new code is checked in against a branch. GitHub sees that the commit has occurred, and automatically executes an “action” based on this commit occurring:

Every time I commit to the build branch, this action will run. So I can branch off build and work on something new and exciting. When I’m happy with it, I just merge it into the build branch, push it, and this action will run.

You may notice that there are two steps: the first is build, and the second is deploy. The reason for this is that you could probably build your app anywhere in the world, but you need to run it somewhere specific. For me, that means I can have my application build on the GitHub agents for free, and when it is successful, start a job on the hosting server to then deploy the app.

Starting out by building our app

Without building our app, we’d have nothing to deploy! The build job carries out the task of building the application. It does this by bringing in all the dependencies, carrying out the build, and then creating packages for deployment.

In my case, I have three things to build. An Angular client app (ngPlayble), the .NET backend (PlaybleWeb), and a console app that executes every so often to collect details (PlaybleScraper):

And then the deploy job picks up these produced files and deploys them to the server:

So, right now, I have a build job that runs, and then a deployment job. Most consequentially, this particular build is tied back to a specific commit hash.

Benefits of automatic builds running

When I had to build my applications locally and then create a deployment package, I was introducing a problem I didn’t know about. This is why.

• On a Monday, I build my application and package a software release.
• On a Tuesday, the package is deployed.
• On Friday, a bug was discovered.

Considering multiple commits each day, how would I know exactly which commit had been deployed into production? Would I instead try to fix the problem within the codebase (as it was on Friday) and then push that into production, causing another problem?

With CI/CD, the product of the build is always attached to a specific commit hash. So you know exactly which version of your code had the bug. This eliminates hours of trying to find this in the first place and possibly creating more problems along the way.

Eventually, I retrieve this commit hash from Git during the build process and embed it into the build in a visible place (usually in the login screen). This way, we don’t have to guess what we’ve deployed.

A lot of companies do this. Even the software that my car runs has a commit hash at the end of the software version. Crazy to think that a Tesla engineer could look at this hash and refer back to their source control to know exactly what software my car is running:

The final realization of this, and what I do in my apps, is I expose the Git commit hash via an API action, and then embed the commit hash into the client app. That way, the client app can check that the server commit hash matches. If the server or client doesn’t deploy properly for whatever reason, I know before I hit weird problems with my app.

How should we use CI/CD pipelines?

In earlier days of CI/CD, we had visual designers who could use to describe how the software should be built. These were quite easy to use. But the problem is, over time, it would be difficult to see how our build pipelines changed as they were represented visually.

This led to a gradual change to most build and deployment pipelines being controlled through YAML. I will admit, I am not a fan of YAML: I think the tab spacing thing is needless and leads to a lot of easy-to-avoid problems. But fortunately, you will not spend much time writing YAML, but instead writing scripts to control your build.

What’s the reason for this? Various CI/CD providers provide all these amazing actions to automatically install tools, do your builds, run the tests, and so on. And it certainly makes life a lot easier.

And we want life to be easier! We don’t want to fiddle about with this stuff forever. But the problem is, you actually want to keep the use of these tools to a minimum. The actions that install tools for your build, you should use. But the actual build of your application should be controlled by a shell script (or equivalent).

Why? When tools are installed into your environment, they will frequently use the cache of the provider to speed up subsequent builds. Tool installation is something that will probably exist on any CI/CD provider, so we can be sure they will be available no matter where we are.

However, using the built-in tools needlessly locks us into a specific CI/CD provider. In my case, I use Azure DevOps for work, and GitHub for my personal projects. Wrapping my build script into a monolothic build.sh or build.ps1 works best for me, because it will work between CI/CD providers without much fussing about.

Here’s the tool setup:

And the actual build process (as this is a side project, I’ve been lazy and have inlined the build script where I should have had it as a separate file, but I can always circle back to that later):

Because my build scripts are checked in alongside my code, I can easily see how these deployments have changed over time.

CI/CD saves our precious time

Originally, I would have to build my application, and then copy the resultant files to the server. This is all well and good on my computer at home, but as the parent of a very active toddler, I’m frequently away from home. Trying to remember where to connect to — and where to copy things to — can become a bit of a burden.

With my CI/CD setup, I can work on my application anywhere, and then just merge my changes into my build branch and push. After this, the build runs, and then the deployment runs shortly after.

The benefits of this are obvious, but there have also been a couple of times I have pushed code and started a build, only to realize half an hour later that I had introduced a problem. On my phone, I’ve edited the build process and then recommitted to the build branch. The build runs again, and the issue is resolved.

Applying our CI/CD to your “real” job

We all think that every development shop already has simpler concepts like CI/CD down pat, but the fact is, a lot of places are still compressing their packages and sending them for deployment manually. Maybe the investment in adopting CI/CD is seen as too great, or maybe it’s hard to get all the required teams on board with it.

Here’s how you can do your best to adopt it into your deployment workflow:

• Remove the magic: Your app should build in a pristine environment. If you have build-time dependencies, you should automate the creation of your build environment via Docker (if you can build your app on Linux) or Vagrant (if your build requires Windows). Having your app only build on “that one pc in the office” is a bad idea anyway, so put the work in to make your build environment idempotent.
• Connect the agents: After your build environment is set up, find the right agent for your environment. Agents run on your environment, and run the build script that describes how to build your app. They work well to integrate into corporate environments with proxies etc.
• Create the build scripts: Most CI/CD providers use YAML to define how the build process should work. You essentially just want to have a file that clones your solution, uses something like a shell script or PowerShell script to run the build, and then uploads the output of the build (the artefacts).
• Work with the environment team to use the agents to handle the deployments: Setting up your build environment and installing agents = no problem. Setting up the agents on your hosting servers or somewhere with access to the hosting servers = possibly a much bigger problem. 90% of this will be selling the idea of automated deployments, and why they make sense. When you land it, you’ll be all set.

It could even make sense to land the first three steps first, and then wait a bit before trying to connect the deployments the whole way through. Give the value in the automated builds some time to be evident, and use that to help the automated release rationale.

Make continuous integration and continuous deployment part of your software today

It’s easy to think that all software development companies already have these concepts down pat, but the stark reality is, a lot of them simply don’t. It’s hard to invest the time and effort into new things in the software development space. But passing up the benefits of CI/CD is leaving your organization open to unnecessary instability and possibly even downtime.

How has CI/CD helped you in your projects? Be sure to let us know in the comments below.

The post Why you should set up CI/CD from day one for your apps appeared first on LogRocket Blog.

Today Quincy Larson interviews Andrea Griffiths, who taught herself programming using freeCodeCamp while working in construction. She moved to the US from Colombia when she was 17, and within 6 months she joined the US Army. She ran a chain of gyms before landing a support role at a tech company, then ascending to Product Manager and ultimately Developer Advocate at GitHub.

We talk about:

• Tips for busy parents who want to learn new skills.

• How AI tools are no substitute for your own critical thinking and problem solving skills.

• How even though it's getting easier every day to learn programming for free, people are so distracted, and for many it feels harder and harder to sit down and do it.

Support for this podcast is provided by a grant from AlgoMonster. AlgoMonster is a platform that teaches data structure and algorithm patterns in a structured sequence, so you can approach technical interview questions more systematically. Their curriculum covers patterns like sliding window, two-pointers, graph search, and dynamic programming, helping you learn each pattern once and apply it to solve many problems. Start a structured interview prep routine at https://algo.monster/freecodecamp

Support also comes from the 10,338 kind folks who donate to our charity each month. Join them and support our mission at https://donate.freecodecamp.org

Get a freeCodeCamp t-shirt for $20 with free shipping anywhere in the US: https://shop.freecodecamp.org

Watch the podcast on the freeCodeCamp.org YouTube channel or listen on your favorite podcast app.

Links from our discussion:

• Article about AI and product management (which includes some blunt takes from Quincy): https://thenewstack.io/for-devs-a-fix-for-ai-complexity-is-hiding-in-plain-sight/

• Andrea's weekly newsletter: https://mainbranch.beehiiv.com/

• Learn How to Learn course by Dr. Barbara Oakley: https://www.classcentral.com/course/learning-how-to-learn-2161

Community news section:

1. freeCodeCamp just published this beginner-friendly back-end development course. You'll learn how to build your own web servers and APIs using Node.js, Express, and MongoDB. freeCodeCamp's website and mobile apps are built using these tools, which make up the popular MERN stack. You'll also get some exposure to database architecture, security principles, testing best practices, and more. (2 hour YouTube course): https://www.freecodecamp.org/news/intro-to-backend-web-development-nodejs-express-mongodb/

2. freeCodeCamp also published a comprehensive Blender and Three.js course where you'll build your own 3D portfolio piece: a render of an adorable home office. If you're interested in 3D rendering and computer graphics, this is the course for you. You'll learn key concepts like Quad Topology, Raycasting, OrbitControls, and more. By the end of the course, your 3D model will be live on the web so you can share it with your friends. (9 hour YouTube course): https://www.freecodecamp.org/news/create-a-cute-room-portfolio-with-threejs-blender-javascript/

3. freeCodeCamp also published a handbook on using Docker with Node.js. You'll learn how to set up Docker and Docker Compose. You'll also learn fundamental concepts like Volumes, Images, and Containers. This is an excellent resource for you to read through and code along with. Bookmark it for future reference. (full length handbook): https://www.freecodecamp.org/news/how-to-use-to-docker-with-nodejs-handbook/

4. Level up your JavaScript implementation skills with this new freeCodeCamp course on Clean Code. You'll learn how to detect “code smells” and refactor your JavaScript accordingly. You'll also learn how to use ESLint and Prettier to automate some of the more error-prone aspects of shipping code. (1 hour watch): https://www.freecodecamp.org/news/level-up-your-javascript-detect-smells-and-write-clean-code/

5. Classic text adventure games Zork I, II, and III are now open source with an MIT license. Microsoft has published their full source code on GitHub: https://github.com/historicalsource/zork1

6. Today's song of the week is 1985 classic "Something About You" by Level 42. I love the slap bass, the vocal harmony, the falsetto, and the huge synth sounds. It's impossible to listen to this song and still be in a bad mood: https://www.youtube.com/watch?v=zpdQQoc-gkk

A customer was writing a Win32 program and was looking for something like a combo box, in that it gave the user a choice among various fixed options, but sometimes the program would come up with a new option that wasn’t on the list, and it would want to show that as the selection. On the other hand, the customer didn’t want to give the user the option to enter arbitrary text. Users still had to choose among the fixed items in the combo box or the new option that was generated on the fly. The customer didn’t want to add the new option to the dropdown list, which means that the CBS_DROP­DOWN­LIST style would not be appropriate, since that forces the selection to come from the list. What they wanted was for the combo box to act like a traditional combo box with edit control, except that the user can’t change the text in the edit control.

The solution here is to make the edit control read-only.

You can get the edit control handle by calling Get­Combo­Box­Info and then sending the EM_SET­READ­ONLY message to the window identified by the hwndItem member.

case WM_INITDIALOG:
{
    HWND combo = GetDlgItem(hdlg, IDC_COMBO);
    SendMessage(combo, CB_ADDSTRING, 0, (LPARAM)L"Fixed item 1");
    SendMessage(combo, CB_ADDSTRING, 0, (LPARAM)L"Fixed item 2");
    SendMessage(combo, CB_ADDSTRING, 0, (LPARAM)L"Fixed item 3");

    COMBOBOXINFO info = { sizeof(info) };               
    GetComboBoxInfo(combo, &info);                      
    SendMessage(info.hwndItem, EM_SETREADONLY, TRUE, 0);
}
return TRUE;

The Get­Combo­Box­Info function is admittedly a bit hard to find because it’s not a message or window style, so it’s not in a place that you naturally look when trying to find information about a combo box.

The post How can I have a Win32 drop-down combo box with a read-only edit control? appeared first on The Old New Thing.