Forem: Andrew Schmelyun

I built a free tool to help content creators collect ideas and feedback

Andrew Schmelyun — Sun, 12 Nov 2023 08:03:04 +0000

I've been a content creator in the programming space for the last few years, and during that time I've gotten a lot of ideas from a variety of different sources.

So I built this: Suggest.gg

Where the idea came from

For a while, I would add suggestions that I received to a Trello board or Notion database to stay organized, which worked out well enough. It felt clunky though. Other people couldn't see my lists so I regularly got the same idea more than once, and I had no way of knowing what the most popular suggestions were.

That wasn't a huge deal, I usually just picked out a random idea to work on next and went with it. But as I continued to grow, so did my audience, and the number of requests that I got increased. Moving forward, my goal became to appeal to what my audience wanted to see most.

As an attempt at fixing this, I'd run polls a couple times per month with a few different topics and see what people were most interested in.

That helped, but got repetitive, so I figured that there has to be a better way to solve this issue. So, I did what any software engineer would do and started building an app to scratch my own itch.

What Suggest.gg does

Inspired by roadmap applications for software development, Suggest.gg lets content creators organize ideas into different statuses, accept new suggestions, and collect feedback from an audience.

You have a public profile where viewers can see what you're currently working on, what's been suggested by other people, and what has been finished up. They can vote on ideas, and leave more detailed feedback in the form of comments.

You also get a creator dashboard to monitor incoming suggestions, view basic visitor statistics, and manage your existing ideas. You can also customize your profile with a few different themes.

And well, that's basically it!

Suggest.gg is 100% free to use with unlimited ideas, suggestions, votes, and visits. I built it to serve my own purposes, but wanted to make it accessible to the larger content creator community.

I hope this helps others like me be less overwhelmed and understand what their audiences are most eager for.

What's next?

I'm working on a pro tier that'll include some additional perks. Things like advanced analytics, multiple boards, and more unique theming options. I'd like to continue working on the platform, improving it in any areas and adding useful features.

If you're a content creator or know one who might find Suggest.gg useful, I'd love it if you tried it out and tell me what you thought!

The crippling problem of being able to build whatever you want

Andrew Schmelyun — Thu, 26 Oct 2023 07:45:52 +0000

I currently have 143 different ideas in a backlog waiting to see the light of day, and it is a constant source of anxiety. Maybe you have a similar list of your own, and like me, tell yourself "if only I had the time to work on them".

I feel that we, as developers, programmers, and software engineers, face a unique problem when it comes to our spare time. We collectively possess the ability to bring our own ideas to life out of thin air, in exchange for nothing but time.

Once we hit a certain point of knowledge and understanding, it can become trivial to put together cool and interesting projects, open source libraries, and full-fledged SaaS apps. If it's so easy though, why do so many of us struggle to get projects out into the world?

In this article, I'm going to take a look at some of the common obstacles and origins of these issues, and wrap up with some solutions that helped me build my ideas faster. Let's get into it.

Limiting factors

Talking with people in other professions, like woodworkers or contractors or mechanics, they also have ideas for fun and interesting projects that they'd like to take on in their spare time. This isn't a unique thing to just software engineers or the tech circle.

These folks that possess the skills and knowledge to make their ideas come to life are usually bottle-necked by something physical: raw materials, specialty tools, or expensive equipment. They'll likely have to dip into their own pockets in order to get started on a project.

There are limiting factors, money mostly, and space, that greatly narrows down their focus of potential projects to work on.

This problem doesn't exist in the software field, or at least nowhere near to the same extent.

When building a website or app, arguably the largest financial barrier is cost of development. But when you are a developer, you possess unlimited quantities of that normally-limiting material.

It's like a woodworker who lives in a forest of pristine walnut trees or a mechanic who owns a used car lot. Being able to build the software you want cuts out the largest expense, so then you're bound by just one restriction: the amount of time you can reasonably spend working on a project.

This sounds great! For developers who enjoy building things on the side, if we are able to make it, we can make it.

But wait a minute... I have all of these ideas to choose from, which one should I start first?

The indecision

If I can build anything, then what should I pick to work on?

Depending on who you are, this could mentally cripple you to the point of exhaustion. Full stop.

I mentioned earlier that I have over 140 different ideas for side projects. Here's a little bit of fun math that I did in my head while writing this article.

If:

Only 1 in 3 ideas are viable, interesting projects to build, and
Each one takes approximately 2-3 months to get an MVP out, working in my free time

Then it would take me over 10 years to get through my current backlog of viable ideas. And that's assuming a whole bunch of things like:

I stop adding my usual 1-2 ideas a week
I don't get sick, injured, or have a major lifestyle change
I don't have an increased workload

And that's just counting development to the point of releasing a minimum viable product. This doesn't include maintenance, support issues, devops, maybe some billing, occasional marketing, urgent security patches, and any other ongoing work that will have to be done if I want to support this project after launch.

And why wouldn't I? I took the time and effort to create something from scratch, I'd want to see it through til the end. I also don't want to stagnate and disappoint my users or other developers, and I should take pride in what I've built.

This leads to a new problem, compounding time based on the amount of projects you're maintaining.

Compounding interest

In the world of both open source and paid projects, you're bound to have maintenance requests, bug alerts, and other notices coming at you on a regular basis. If you're the sole developer and maintainer of said project, library, or application, then it's your time that goes into handling these items.

The more projects you release, the more potential time you lose with recurring support and maintenance. This can easily compound to a point where you're unable to dedicate time to building new projects, and will have to make the decision between dropping your support of an existing project, or not taking up a new one.

I feel like with each project I take on, I sit and watch as a scale weighs through the pros and cons.

Will I come out of this experience in a positive light when the project is over, or will I be burnt out?
What if this takes off and I feel obligated to maintain it for years to come?
If I slow down or stop fixing these issues, will my community react negatively?

These might seem paranoid or excessive to think about for every project that I start, but honestly, I've seen each of the above points come true for multiple different projects throughout my years as an avid open source contributor.

I've talked enough about the negatives, how about some actions that we can take to actually address the problem. How can we, as intrepid developers, actually complete projects and get finished ideas out into the world?

Potential solutions

There's a few techniques I've found over the years that have helped me more consistently move projects into the finished basket on a more frequent basis. Let's check them out.

Organize your ideas.

This is arguably the most important thing, period. If you're someone like me, new ideas spring up at you all the time. Inspiration for new projects come in the forms of a friend complaining about an existing app, a Tweet asking for a service that doesn't exist, or even passing shower thoughts.

It's best to get these out of your head, and down onto a stationary media. For me, that's a Kanban board.

I have four columns for my ideas: Backlog, Promising, Working On, Monitoring, and Archived. If I think of an idea, I create a new card in the Backlog and dump as much info as I can into it. Framework to use, pain points that I could encounter, potential domain names, you get the picture.

Then, I do nothing.

I don't immediately drop everything to pick up this new shiny project. Instead, I let it marinate outside my mind. If I keep coming back to it days or weeks later, I move it into the Promising column. The next step could be weeks, months, or sometimes years away.

Don't spread yourself thin.

I always have a voice in the back of my head saying "you can squeeze in an extra project, don't worry!". It's a liar. If I decided to take on a new project while trying to balance everything else, something will suffer. There's only so much quality time and work that I can deliver in a day.

So, I don't pick up anything else until I have the bandwidth to sit down and focus on it. This usually means making the conscious, mindful decision to hold off on any new ideas until something I'm already working on makes it out of the Working On column.

This is where the root of a lot of my frustrations used to lie. I believed that if I wanted to focus on something else and not stretch myself thin, then I needed to be completely finished with what I was already working on, 100% done.

But that led to eventual disdain for the projects I was once excited for, so I decided to try something a little different.

Release fast and get feedback.

Instead of waiting for a project to be fully complete when I'm working on it, I now tend to release as early as I can. By getting the bulk of the development work in a "good enough" spot as fast as possible, I maximize my available time that I have to work on projects and can start getting feedback as soon as possible.

This usually means throwing the project up on GitHub or a purchased domain, writing some halfway-solid documentation, and sharing it out to Twitter, Reddit, and if I'm feeling particularly brave, Hacker News.

This might make a lot of people nervous, and it's understandable. The internet, and especially the tech side of it, can be a pretty uncaring place. But, it can also be pretty great.

At this point, one of two things usually happens for my projects:

I start getting some solid feedback. People are interested in the project or checking it out on their own, and I'm seeing comments, opened issues, and messages.
No one cares and no one really pays attention. This sucks, honestly, and is a pretty terrible feeling. But... it hurts a lot less when you don't sink countless hours into a project perfecting it, only to get a similar response.

If I find out early that I didn't hit a mark with it, I can move on from this project and start something new! If I start getting some feedback though, the project moves onto the Monitoring phase.

Iterate and set expectations.

Alright, I've got people interested in what I've built, and now I have some actionable feedback coming through, now what?

For me, at this point the project enters the Monitoring phase. The core functionality is there and valid, and now it's up to me to work on features, fix bugs, or approve pull requests. Keep in mind though, depending on just how popular your project gets, this could spiral out of hand. So it's best to set expectations.

Let your community and users know how often they can expect new releases, or how often issues are looked at. You don't have to be a superhero when it comes to response time, and it's an easy way to get burnt out. For me, my goal isn't to make maintaining a project a full-time job in itself, so for a lot of my work I've balanced reponsiveness for new features and issues over working on new projects.

My users don't seem to mind much and are happy when new releases come through, but you'll have to gauge that for yourself.

You don't have to use the above like a roadmap and implement everything I've talked about for your own projects and workflow. Every person's different and what works for me might not work for you. Feel free to pick and choose any of these ideas that sound like they might help you out in your current situation, or scrap them altogether and make something new!

Wrap up

I've started and stopped this article multiple times because I just really didn't know exactly what I wanted to say, it never felt like I was getting my thoughts across well enough. So really, this is just a rant about my particular circumstances and how I've felt creating and maintaining paid and open source projects throughout years of my life.

Just know that if you're experiencing something similar, a conflict between the time you have to dedicate and the desire to build, that you're not alone.

Making the case for Laravel as a Next.js alternative

Andrew Schmelyun — Fri, 18 Aug 2023 08:31:32 +0000

Next.js is a powerhouse of a full-stack web framework with features like page-based routing, static-site generation, and dynamic React components, but what if I told you that you could get all of that with just PHP?

Laravel is a PHP framework that's been in development for almost a decade. In that time it has solidified itself as one of the most-loved options for building web applications powering the needs of both startups and some of the largest companies around. It also has amassed a massive community of individuals and organizations that provide world-class packages and libraries to enhance its already renown developer experience.

Within the last year or two, first-party upgrades to the framework and package developers have added a suite of functionality to make Laravel a powerhouse for developing truely full-stack web applications fast and efficiently. In this article I'm going to go through some of the biggest features that Next.js is known for, and offer up examples of similarities found in the Laravel framework.

This isn't meant to be a "who's better" between the two, but instead a showcase of what Laravel can do out of the box. Let's start!

Page-based routing

Next.js is famous for its simple and intuitive page-based routing system. But did you know that Laravel has a similar functionality now? Up until this year, if you wanted to create a new route in Laravel you'd have to specify it in a main routes file. However, a first-party package called Laravel Folio was recently released that enables purely page-based routing, and it works surprisingly similarly to Next.js.

Let's take a look at an example file structure:

resources/
└─ views/
   ├─ pages/
   │  ├─ index.blade.php
   │  ├─ uses.blade.php
   │  └─ blog/
   │     ├─ index.blade.php
   │     └─ [slug].blade.php
   ├─ dashboard.blade.php
   └─ welcome.blade.php

In the above, anything under the resources/views/pages follows the convention of page-based routing. So the uses.blade.php file's content will be visible at our site under /uses .

An index.blade.php file is used to denote the default root view for that particular directory. That means that the blog/index.blade.php content will be visible at /blog. This should seem straightforward and similar to Next.js.

Except, what about dynamic routes? Well, that's covered too!

In the above example, you'll see a [slug].blade.php file. This creates a dynamic route where anything visited under the blog route will be resolved by this view file, with a $slug variable being included that contains the data passed through to the route.

For example, visiting /blog/my-example-post will resolve to that [slug].blade.php page, and if you referenced a $slug variable in it, will contain the value "my-example-post". This can then be used with an internal function to grab a related model, make an API request, or however else you want to use the value passed through.

But we can take dynamic routes one step further.

For our blog, if we were using a Laravel model called Article to hold data for a single blog article, we can actually use route-model binding in our dynamic page-based routes by just renaming that file to [Article].blade.php. Now inside the blade file, the variable $article will be available, containing the entire Article model's attributes!

Static-site generation

Next.js recommends using static generation whenever possible, and it's enabled by default on most pages. Basically anything that doesn't require heavy user interaction can be statically generated on build time and then served up via your server (or better yet, a CDN).

By default Laravel generates every route dynamically. It's not slow since there is a route cache which helps cut down on a lot of the PHP interpretation, but the fact still remains that a Laravel app relies on dynamic markup generation.

We can change that though!

There's a package, laravel-export, that comes from a well-respected third party. After installation there's zero necessary configuration before our entire site can be statically generated with a single command, php artisan export.

This will crawl our site, following links on pages, and save the rendered markup to a dist folder in our application's folder structure. It also works well with the Folio page-based routing mentioned above.

Like with Next.js, we can modify the behavior of this through some small configuration changes in our app.

We can specify paths to exclude from the crawler, programmatically turn it on or off, and write hooks that fire off commands before or after the export runs (for example, if we wanted to deploy the exported site files to a production server).

Unlike Next.js, there's no equivalent of a getStaticProps method that runs when building the exporter. You can always include a function in the body of the Blade template if you're using something like Folio, which will run as each page is compiled, although that'll also occur outside of the exporting as well.

Server-side rendering

While using Next.js you need to include a getServerSideProps method to enable SSR, but PHP comes with server side rendering on by default!

In normal circumstances, PHP is rendered on each request through the server. This means that writing PHP code in your blade files guarantees that the content of your functions will be hidden from the generated markup that comes back to the browser. Those files are never accessed directly, and so this adds a layer of security to your application by default.

Going deeper than just blade files, Laravel is a full MVC framework and so includes things like Models and Controllers out of the box that can be used to organize your server-rendered code. Authentication is also baked in by default, and with first-party packages like Breeze, Sanctum, or Socialite, you can include user registration, login, API-based authentication, social sign-ups, and role-based permissions with near zero configuration.

A similar out of the box piece to look for is a database. Laravel includes an abstraction layer called Eloquent that makes it easy to interact with your database of choice. It's a full ORM that can be used to create, read, update, and delete records, and can be used to build out more complex relationships between models.

Single page components

Some of the beauty of Next.js comes from the fact that you're using the React library, and all of the wonderful developer experience that comes with it. This enables you to easily build dynamic user interfaces and responsive views with relative ease.

Everything can also be self-contained inside a single page component. Can this be done inside of our Laravel app since everything is server rendered by default?

Up until recently we've had to install and configure a frontend framework to get that functionality, but that requires a separation of concerns and the maintanence of two different codebases. Instead, we can use LiveWire and Volt to give us dynamic, single-page components with just PHP.

Let's say that in our [Article].blade.php page mentioned way above that after each page's content we have a subscription form. We can use these two packages to build a dynamic component into our existing page using PHP and Laravel. It might look like this.

<?php

use App\Livewire\Forms\SubscribeForm;
use function Livewire\Volt\{form};

form(SubscribeForm::class);

$save = fn () => $this->form->store();

?>

<form wire:submit="save">
    <input type="email" wire:model="form.email">
    @error('form.title') <span class="error">{{ $message }}</span> @enderror

    <button type="submit">Subscribe</button>
</form>

Now when our page is visited or rendered, we'll have a form at the bottom that the user can fill out and submit without needing to perform a full page refresh!

Unlike Next.js though, this interactivity is dependant on server rendering. LiveWire uses JavaScript on the frontend to hydrate these components and provide client-side interactivity, but the core functionality and reactivity depends on the server to manipulate state and perform the functions requested.

Development environment included

With Next.js, you have an included development server that's ran with npm. With Laravel, there's a few different options for a local development environment.

First, if you have PHP installed locally on your system, then it's as easy as running:

php artisan serve

This boots up a local PHP server instance, included in the actual language itself. It's a bit limited, blocking by nature and without a database, but it gets the job done and is responsive enough to use for 90% of local development cases.

If you want something more complex with additional features like a MySQL server, Redis instance, or Mailpit box, then you can use the first-party Laravel Sail which comes pre-installed to new Laravel apps. It's a bash script wrapper for Docker that boots up a network of containers and handles your local dev environment setup.

Ease of deployment

Alright, you're ready to release your application to a production environment, now what? Let's assume that we have a mixture of static content and server-side rendered routes, which means we'll need to have a setup that can run our applications dynamically.

For Next.js, this means that we need to have a server provisioned with Node.js. Something like a basic Amazon EC2 instance or a DigitalOcean Droplet can handle that, and the installation and configuration is pretty straightforward. What about Laravel?

Since Laravel runs on PHP, and PHP has been around for decades, getting a server provisioned with the requirements for a LAMP (or LEMP) stack is not too difficult of a task. There's a plethora of options available, from shared hosting to VPS providers. Even managed services like Laravel Forge that can handle the provisioning and configuration of your server for you, similarly to how Next.js has managed application instances with Vercel.

What else?

This article wasn't meant to be a competition between Next.js and Laravel. They're both fantastic batteries-included, full-stack web frameworks that enable you to build applications and ship awesome features.

However, if you're looking for an alternative to Next.js, maybe with something that's a bit more batteries-included, Laravel could be what you're looking for. With a robust ecosystem, a passionate community behind it, and the ubiquity of a language powering over 70% of the web, it's definitely an option to keep in mind.

AI is a fad and programming is dead

Andrew Schmelyun — Mon, 01 May 2023 05:34:58 +0000

These are the two prevailing point of views that I’ve seen spread the most on social media.

On one hand, you have people saying that programming as a future career is essentially dead, and it’ll be a couple of years before humans writing code is made obsolete. Then there are those who think that LLMs like ChatGPT and LLaMA are party tricks, nothing more than a fun little experiment that provides minimal value to those building software.

I think the reality is more nuanced than that, and both points above can be harmful or anxiety-inducing to people who just started in the software engineering field or are interested in it as a career path. I’d like to take a little time and go over what I think AI will change in this landscape over the coming years.

If you’d like a quick breakdown or tl;dr of what’s going to be in this article, the main points are:

AI will continue to improve, probably in an S-curve fashion, but we don’t know where on the curve we currently sit.
LLMs are unlikely to take jobs away from software engineers, but they will enable teams and individual contributors to be more efficient, and get more done with less time and resources.
Tools like ChatGPT usually require you to give detailed instructions in a logical format to yield good code results, this is essentially the role of a programmer just in a new, esoteric language.
If AI improves to the point that humans are removed completely from the software process then we have made it pretty much to AGI, at which point we have much bigger problems to worry about based on our current societal structure.

Still interested? Let’s continue!

AI improvement and the S-Curve

AI has improved drastically over the course of the last year or so. We’ve gone from some basic sketches and drawings to full-fledged generated movies based on images, text, and speech a la Midjourney and others. OpenAI’s improvements to the GPT model has shown incredible promise in generating text and code. There are AutoGPT experiments, where talented developers have been running processes that spawn LLM entities and have them loop over and perform actions to finish complex multi-step assignments.

All of these might make it seem like we are advancing at an exponential pace in this field, but that might not be the case.

Technological advancements have historically been shown to happen on something called successive S-curves. A technology will slowly advance and then rapidly take off, before slowly plateauing out for a while. A new iteration happens that starts the same cycle over again, but this time at an overall higher level. Zooming out, the graph appears linear but is instead made up of multiple iterations of these curves.

It’s not a bold assumption that AI might follow the same path (at least for now), so the question becomes “where are we on the current curve?”. Maybe toward the bottom, right before accelerating exponentially up, or towards the top with little room to advance at the moment.

If I had to bet on a particular point in the line, I’d say that we’re right before the plateau.

I think we have a small amount of advancement to go with LLMs and the technology that currently surrounds them and AI in general, but I think that we’re missing something that will take time to fully provide.

As more and more AI generated content comes out (video, speech, code, images), more and more people can recognize it for its uncanny-valley-ness. Like most projects, I believe that the missing 10% will take 90% of the time and effort to perfect.

How long until we hit that next curve though, and exponential improvement begins again? That’s difficult to say, and no one person should be able to answer that.

LLMs are the next step in IDE advancement

Getting back on track about programming though, we have seen a drastic improvement and adaptation of models like OpenAI’s GPT in the coding world. Tools like ChatGPT, GitHub Copilot, and now Copilot X have improved the efficiency of developers around the globe.

But, they’re not replacing programmers, they’re tools in a utility belt enabling programmers to work better.

The first time I went from a text editor like Sublime to a full-fledged JetBrains IDE was insane. My productivity skyrocketed as I suddenly had access to auto-completion, automated refactoring, integrated testing, and deeper connections to my project’s dependencies. I was able to produce cleaner code at a dramatically faster rate.

These AI tools are just the next logical step in that same improvement process.

I’ve been using Copilot and ChatGPT in my personal projects since the start of the year, and I have noticed a similar efficiency improvement.

A lot of work done in new projects are tasks I don’t have to put a lot of thought or effort into, but that take up time. Creating automated tests, frontend templates, new classes, or formatting data outputs, I can complete these items 10x faster now that I have the help of these tools. They just understand what I’m trying to do, and scaffold out the code necessary in my project to accomplish it.

Going deeper, there have been times where I need to create a complicated function body or work with a library that I’m not super familiar with. I can type in a basic comment for what I’m trying to build in that instant, and the AI spits out a code block that’s usually helpful in satisfying the requirements I’m after.

For an example, I was recently in a PHP application and wanted to work with a popular FFMpeg library with pretty complicated documentation. Instead, I just wrote the following:

public function formatVideo($video)
{
    // use ffmpeg to convert the video to a gif
}

Hitting enter after I made that comment produced succinct code that I could use in the rest of the project, with a few minor tweaks.

But the fact of the matter is that it saved me a ton of time. If I had known the exact details of the library, sure, a minute or two might have been shaved off. But because I was in this realm between knowing the language but not a particular library, I knew exactly what I could ask and could use the code given to me immediately. All without having to take time poring over documentation, Stack Overflow questions, or trial and error.

This is where these tools and AI for programming really shine, it enables you to work better.

Two things though.

It’s over-confident. There have been multiple times where the AI has hallucinated arguments or functions that don’t exist in my project or a library I’m using. I might be able to nudge it in the right direction after a few retries, but sometimes it goes completely off the rails and writes code that straight up does not accomplish what I wanted it to. This has been pretty rare, though.
It’s not connected. ChatGPT and Copilot are great at creating snippets of code that perform a specific function from given input. An entire application is still a bit out of reach. First, there’s a barrier for the amount of text, as even GPT-4 is limited by 8K tokens (around ~6k words). Second, even with the use of vector databases and AutoGPT, the models have a hard time sticking to a single development style or accomplishing an overall directive in a program that’s just above moderately complex. Ask them to create a todo app and it’s likely to be fully functional. Ask for something like a CRM to handle leads for a barbershop and it’s more likely to start on the right track, but end up with missing functionality or ineffectual code.

That last part in particular brings us squarely to our next section.

Programmers are translators for a logic language

If you ask a lot of people what their definition of a programmer is, you’ll likely get a lot of responses that boil down to “someone who writes code”. And while this isn’t incorrect, it’s also missing a huge part. A programmer, software engineer, developer, or whatever title you choose, is a translator for a language that deals in logic.

Your goal as a programmer is to take a concept, an idea, or a workflow in a language that you can understand, and translate that to a language that a computer can understand. This programming language is designed to prevent ambiguous statements and deal in pure logic.

Let’s take the sentence “When the button is pressed, change the background to red”.

If you’re a person in a meeting with other people from your team, you all might intuitively know exactly what is meant by that.

But if you’re a computer, you have a ton of missing information. What button? What background? What shade of red? What if it’s pressed again?

We can redefine our sentence again to try to remove ambiguity. “When the button with the ID of ‘clicky’ is pressed, change the background of that same button to a color with the hex value #FF0000”

Written in JavaScript it looks like this:

document.getElementById('clicky').addEventListener('click', function() {
    this.style.backgroundColor = "#FF0000"
})

If you’re familiar with this programming language, and you were given the code above and asked to explain what it does, you might produce a sentence similar to the second one above.

You’ve translated JavaScript into your native language.

This is the heart and essence of programming, and is one of the biggest reasons I believe that the profession will be around for quite a while, even in the face of advancing AI tools.

There’s hundreds and thousands of threads online where people ask “Why isn’t ChatGPT producing the code I want it to?” and inevitably the answer comes down to:

“You need to know how to talk to it.”

Well, if I need to use a specific language to talk to this tool and get back accurate data every time, then I’m just programming with a natural language. This isn’t a new concept, it’s just that with the breadth and complexity that LLMs offer, the barrier for entry is lower.

Even if building an application has been reduced down to typing in prompts in a tool like ChatGPT, if you have to use a specific language to get it to create a reliable output that works every time, you’re in essence still programming.

Looking at the present, trying to build an application with an LLM with the current limitations of the models means that you’re likely going to have to put some of the pieces together yourself. This still constitutes programming, and you’ll need to know some basics about what the language is that it produced code for you in and where to put the pieces it gave you.

But let’s say that things advance to the point where that’s trivial or useless, because the AI will do it for you anyway. You say “Alright, compile these assets and publish them on example.com”. At that point, why even have a programming language? Let the AI be the layer between your data and your result, skipping the middle step entirely.

Well at that point, we’re basically at AGI.

AGI replaces everything

Let’s say that everything above has been perfected and there needs to be almost zero human intervention needed. You can simply have a prompt attached to a database (also managed by an AI) where you can simply ask for any dashboard, result set, or functionality that you could from a program. What then?

If AI is powerful enough to remove human intervention and oversight from the programming realm, then it has gotten to the point that it can replace almost every creative and knowledge worker profession in existence. This would likely lead to a worldwide economic downturn as more than 60% of the labor force is no longer required.

At the very least, we’d need UBI, or taken to an extreme, FALC.

This of course implies that every business, everywhere, would hop on this technology immediately. While most companies are always looking to maximize profits and increase efficiency, a lot of the business world turns at a slower pace than the technology realm likes to believe.

I know teams that are just now picking up tools like Docker, or working with frameworks like React. The enterprise world moves at a very slow pace, and even if a tool was provided that could perform 90% of a team’s job developing new products, maintaining legacy software and complex inter-dependent systems will still need to be done during, or even after, an adaptation of an AI system.

The software engineering profession has some ~100k open positions in the US alone, even if complete automation was made available today, there would be a large amount of time before full adaptation was reached.

Wrapping up

This piece was mostly written as a way of getting a bunch of different thoughts I’ve had about AI and the programming profession out of my brain. It’s not a secret that I’m a very anxious person, and I won’t lie and say that I’m not nervous about my future as a software engineer.

However, I’m excited for the tools that are being created to increase my productivity and allow me to be a better programmer. I encourage anyone out there interested in this career, or just starting out, to keep learning and utilizing the tools and techniques available to you.

I think that we’re going to see a lot of interesting advancements in both AI and the software development world over the next few years, and it’s an exciting time to be in the field. I also believe that given the current trejectory, this profession is not a dead end.

Developers may become a lot more efficient over time, leading to smaller team sizes and available company roles. However, startups and smaller enterprises can utilize the same technology and low barrier of entry to launch new products and services that before, would have taken more time and effort.

If I’m completely wrong about the above and programming is obsolete in a few years, well then it’s been a fun ride and you can catch me in a cabin in the woods gardening and making cabinetry.

Intercept and inspect http requests with reqon

Andrew Schmelyun — Sun, 18 Sep 2022 06:01:35 +0000

A few weeks ago I had an itch to scratch, I was working with a legacy application that was sending out a ton of curl requests to a production service. The problem was, I had no idea what was in them.

Sure, I could have dug through the spaghetti and documented each one, but I needed an answer pretty quickly and instead just started var_dumping the requests to local text files. I thought, "there's gotta be a better way than this", and figured if I could just change the external API endpoint to something local, I could capture the requests and check them out in real-time.

After searching for a while I found a few paid and hosted services that offer what I wanted, but nothing that was local or open source. So, I decided to make it! What I came up with, is reqon.

Installation

You'll need to have npm installed and a node version of 16.0.0 or higher. Then, in your terminal just run:

npm install -g reqon

That's it!

Usage

Run the reqon command in your terminal to start listening for requests on a local server. There's a few different options you adjust to your liking.

reqon [options]

options:
  --port=<port>             sets the port to listen for incoming requests
  --dashboard-port=<port>   sets the port the dashboard is available on
  --save-max=<number>       changes the max number of entries saved locally
  --save-file=<path>        changes the filepath used for local db, json ext required
  --no-dashboard            disables the dashboard, --dashboard-port is ignored
  --no-save                 disables saving locally, --save-file + --save-max ignored
  --help                    what you're seeing right now :)

Some of the options above have defaults associated with them, they are:

port default is 8080
dashboard-port default is 8081
save-max default is 50
save-file default is ~/.reqon/db.json

Viewing requests

Whenever a request is made to the listening endpoint, it's recorded and displayed immediately in the terminal. The details include the full route, http method, headers, url query variables, and request body.

If you'd prefer something a bit more... easy on the eyes, a dashboard server is also spun up by default. It can be visited to see all of your current and past saved requests, along with their details, in a simplistic but effective layout.

By default, requests are stored locally in a JSON file with the help of LowDB.

Wrapping up

Thanks for checking this project out!

If you end up using it and have any suggestions or issues you'd like to discuss, please feel free to let me know. You can put in a request directly on the GitHub repo, or reach out to me on Twitter.

The difference between Traits, Interfaces, and Abstract Classes in PHP

Andrew Schmelyun — Sun, 07 Aug 2022 05:53:45 +0000

If you've been working with PHP regularly, chances are you've run across an Interface, Trait, or Abstract Class. At first glance, they might appear to have a few similarities between them, and it can be hard to make out their differences and use cases. By the end of this article, you should be able to easily tell what sets them apart, and when it's best to use one over the other.

tl;dr

An Abstract Class can contain method signatures as well as common methods, but can't be instantiated on its own. Good for creating a common parent to share between classes.
A Trait is a group of properties and methods for code re-use, and multiple can be added to a single class. Good for organization and reducing repetition.
An Interface is a set of method signatures to enforce a particular implementation in the class they're added to. Good for adding structure and standardization.

Want to learn more about each of these? Keep reading!

Abstract Class

An abstract class is structured a lot like a normal class, but contains abstract methods as well. Unlike a normal class though, it can't be instantiated by itself. They make good starting points for classes that would likely share a common parent.

Let's say that we had Cat, Dog, and Hamster classes. These might share some common methods and functionality, so a parent abstract class could be created to both add shared methods as well as enforce required implementations in the child classes.

A parent abstract class for those might look something like this:

<?php
abstract class Pet
{
    abstract protected function greet();

    public function hasFur()
    {
        return true;
    }
}

We have an abstract method greet() which will force any class extending Pet to implement that method. Then we have a public hasFur() method which will be accessible to any object created from a class that extends this abstract class.

So now we can create a class for a particular kind of pet:

<?php
class Cat extends Pet
{
    public function greet()
    {
        return 'Meow!';
    }
}

$cat = new Cat();
$cat->greet(); // Meow!
$cat->hasFur(); // true

Some takeaways about abstract classes:

Can't be instantiated on their own
Abstract methods just declare a signature (no functionality)
Used by a child class with extends
Act as a sort of partially-built class

Trait

Traits are a way to re-use code in multiple (and sometimes completely unrelated) classes. Unlike abstract classes, multiple traits can be used on a single class with the use statement.

They're regularly reached for to group together somewhat related methods and properties, adding that functionality to classes they're used in.

For example, we might have two traits HasLegs and HasFins:

<?php
trait HasLegs
{
    public function walk()
    {
        $steps = 0;
        while (true) {
            $steps++;
        }
    }
}

<?php
trait HasFins
{
    public function swim()
    {
        $laps = 0;
        while (true) {
            $laps++;
        }
    }
}

We're continuing with the animal examples from earlier, so let's say that we had a Cat object that clearly has legs and can walk. We can use our HasLegs trait to give our Cat class a walk() method that can be used:

<?php
class Cat
{
    use HasLegs;
}

$cat = new Cat();
$cat->walk();

Or, what if we had a Duck object, that kind of has both legs and fins? We can use both traits and give our class walk() and swim() methods:

<?php
class Duck
{
    use HasLegs, HasFins;
}

$duck = new Duck();
$duck->walk();
//or
$duck->swim();

Some takeaways about traits:

Perfect for code reuse
Implemented in the class body with use
Multiple can be used in the same class
Can have both properties and methods

Interface

Interfaces are a way to enforce specific implementations in classes that use them. Interfaces can only contain method signatures, there's zero functionality in them at all. They're mostly there to ensure structure and act as blueprints for building classes.

Let's take this example of an interface:

<?php
interface Bug
{
    public function legs();
    public function eyes();
}

Again, there's no implementation of the legs() and eyes() methods, just the signature that they're required in classes that include this interface. So, if we create classes that implement our Bug interface, those methods need to be available in each of them.

<?php
class Spider implements Bug
{
    public function legs()
    {
        return 8;
    }

    public function eyes()
    {
        return 8;
    }
}

<?php
class Beetle implements Bug
{
    public function legs()
    {
        return 6;
    }

    public function eyes()
    {
        return 2;
    }
}

So now we have two classes each implementing our Bug interface, which are both required to include the legs() and eyes() methods as well as their own (usually unique) implementation.

Some takeaways about interfaces:

Act as blueprints for classes
Used in the class declaration with implements
Multiple can be used in the same class
Can only contain method signatures (no properties)

Wrap Up

Hopefully now you have a better understanding of the distinctions and similarities between Abstract Classes, Traits, and Interfaces. Each of them are powerful and when combined in different ways can add a lot of power and structure to your PHP applications.

If you have any questions about this, or anything else related to web development, feel free to let me know in the comments or reach out to me on Twitter!

When to use ref vs reactive in Vue

Andrew Schmelyun — Sat, 16 Jul 2022 23:58:15 +0000

The release of Vue 3 introduced two new ways of adding reactivity to data in your components: ref() and reactive(). There's been a bit of confusion surrounding which one's better, or when either should be used. I'm here to hopefully shed some light on their differences, and show how I use them in my applications.

Ref

The ref() method takes a single value, and returns back a mutable and reactive object. Let's take a look at this example code:

const amount = ref(0)

If we wanted to create a method that incremented the amount up by one, you might be inclined to think we can do something like this:

const increaseAmount = () => {
    amount++
}

But with ref() you need to use an intermediary property called value in order to retrieve or manipulate the data inside of the ref object. So instead, you'd do:

const increaseAmount = () => {
    amount.value++
}

The ref() method takes any JavaScript primitive, so you can pass in booleans, strings, integers, or objects.

<script setup>
const active = ref(true)
const message = ref('Hello, world!')
const amount = ref(23)
const user = ref({
    name: 'Andrew',
    email: 'andrew@test.com'
})

user.value.email = 'andrew@example.com'
</script>

<template>
    <h1>{{ message }}</h1> <!-- Hello, world! -->
</template>

When referencing or changing a value (outside of a template), you always have to use the .value property on the returned object.

Reactive

The reactive() method works similarly to ref, but it only accepts objects.

// not reactive
const user = reactive('Andrew')

// reactive
const user = reactive({ name: 'Andrew' })

Unlike ref, we don't need to use an intermediary property like .value in order to get or change the properties of our reactive object. We can just call the properties of the object directly:

<script setup>
const user = reactive({ name: 'Andrew' })
user.name = 'Ashley'
</script>

<template>
    <p>My name is {{ user.name }}</p> <!-- My name is Ashley -->
</template>

An interesting feature of reactive() is that it can also unwrap ref objects for use within itself.

const items = ref(10)
const cart = reactive({ items })

items.value++
console.log(cart.items) // 11

cart.items++
console.log(items.value) // 12

The reactivity between the two also remains, so that updating the value of one triggers an update on the value of the other.

The bottom line

Both ref() and reactive() add reactivity to your Vue components. They allow you to have data that updates and responds in real-time across your application. The differences boil down to:

What data you're passing in, and
If you want to deal with an intermediary property to get the value

For me personally, I usually stick with ref() for reactive attributes in my components. If I start having more than just a few of them though, I create a local "state" object and use reactive() instead.

That way instead of this:

const name = ref('Andrew')
const checked = ref(false)
const games = ref(['Factorio', 'CS:GO', 'Cities: Skylines'])
const elem = ref('#active')

I have this:

const state = reactive({
    name: 'Andrew',
    checked: false,
    games: ['Factorio', 'CS:GO', 'Cities: Skylines'],
    elem: '#active'
})

Well, I hope this made the differences (and similarities) between ref and reactive in Vue a little clearer.

If you have any questions about this, or anything else related to web development, feel free to let me know in the comments or reach out to me on Twitter!

5 practical web dev projects that aren't todo lists

Andrew Schmelyun — Sat, 21 May 2022 08:51:59 +0000

I first learned web development by finding interesting sites around the web and trying to create them for myself. This of course isn't everyone's style of learning, but if you're one of those who thrive on doing to move forward, keep on reading!

Usually when I see examples pop up of beginner projects, they're pretty much the same things: todo lists, text editors, forms, etc. These aren't necessarily bad but they can get a little boring, especially when you start moving up your skillset and want to try to expand your knowledge with more complex projects.

So I put together this little list of ones that I think might be good to try your hand at. They go up in complexity as you go down the list, so just keep that in mind. I've given each one a list of terms you can search to help build them, as well as programming languages or frameworks that might be good to use.

While a project might seem daunting, all of these are made up of smaller parts, so it can be easy to break them down into manageable chunks!

Alright, here they are.

Image slideshow

This will mostly test your frontend abilities, and there's a few ways you can build a slideshow of pictures that rotates through each one. You might be able to try to do something with pure CSS, but adding a bit of JavaScript to the mix will really hone the effect and overall user experience.

Search these terms to help with the project:

CSS transitions
Animating HTML elements
Click events in JavaScript and how to handle them
Image resizing with CSS
Keyboard navigation and accessibility

Some languages and technologies you can use to build this:

HTML
CSS
JavaScript

Markdown previewer

Either with a website or with a command-line application, try creating a way to preview markdown files and convert them to HTML a browser can understand. I write a lot of notes in markdown, but seeing them nicely formatted helps with readability.

Search these terms to help with the project:

Parsing and using command-line arguments
Leveraging third-party libraries
Handling file input
Outputting and styling pre-formatted HTML
Building and distributing a compiled executable

Some languages and technologies you can use to build this:

Go
Node (JavaScript)
PHP

Weather app

This is great because you get to play around with some real-life data. Try creating a website or a mobile application that takes in weather information from your area, and displays it in a nicely formatted way. You can be super complex and show every single data point, or go minimal with just the temperature and basic conditions.

Search these terms to help with the project:

Ingesting and using an external API
Clean layout design and styling
Live updates without having to refresh
Styles changing based on current data
Handling unexpected errors from an API

Some languages and technologies you can use to build this:

Vue (JavaScript)
React Native (JavaScript compiled to mobile code)
Python

Twitter clone

This one you can make as complicated or as simple as you'd like, but it will definitely bring you across both the frontend and backend stacks. At its heart, this project should let someone sign up for an account, create a username, and submit small messages that can be seen on their main feed page.

Feel free to add additional complexity to it in the form of notifications, likes, blocked accounts, reblogs, user settings, etc.

Search these terms to help with the project:

Database design + relationships (one post -> many comments)
Sending notifications
Input sanitization and form submissions
Infinite scrolling
Account authentication and security

Some languages and technologies you can use to build this:

Laravel + Vue (PHP + JavaScript)
Django + React (Python + JavaScript)
Kotlin + Svelte (Java + JavaScript)

Stock market watcher

This takes complexity up another notch by running code in the background, not just while someone is on your site. As a user of this project, I'd want to be able to track specific stock tickers and see their current price on the market.

I'd also want to be notified whenever a price drops below, or goes up to, a certain amount. This will require you to run code in the background of your website to constantly refresh and compare the data coming in from the stock broker.

Search these terms to help with the project:

Background (cron) jobs to watch stock prices
Ingesting and displaying lots of data from external APIs
User authentication and storing personal settings
Formatting and sending email and text notifications
Intricate graphing with or without third-party libraries

Some languages and technologies you can use to build this:

Rails + Hotwire (Ruby)
ASP.NET + Blazor (C#)
Laravel + LiveWire (PHP)

Conclusion

I hope some of these projects have inspired you to look in more uncommon directions for ways to help you hone your programming skills. To this day I'm still building things in my free time in order to learn new frameworks, languages, or just to see if I can actually do it.

If you have any questions about this, or anything else related to web dev, feel free to let me know in the comments or reach out to me on Twitter!

I built a receipt printer for GitHub issues

Andrew Schmelyun — Fri, 25 Mar 2022 07:15:12 +0000

I have a lot of side projects on GitHub. Some of them are kind of popular, and I tend to get issues posted from time to time. The problem though is that usually they kind of get lost in the mix of my emails, or I forget to go through my repos and add new items to my todo list.

I've been occasionally writing new issues down on sticky notes whenever I see a notification for an issue, but I always wanted an excuse to streamline the process a bit more. After seeing a receipt printer spitting out orders while grabbing some take-out the other day, I wondered if I could use one to print out a ticket each time an issue was added to one of my repos.

Spoiler alert, it worked!

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

So let's dive in and I'll show you exactly what I used, and how I set it up!

Hardware list

In order to get started, I'll need a thermal receipt printer and some way to get data into it. I ended up using:

Epson TM-T88IV
Raspberry Pi Zero W
Micro USB to USB adapter
USB Type-B cable

The reason that I went with an Epson thermal printer is that they use the ESC/POS command set, for which there's established libraries in a variety of programming languages. Plus they're pretty ubiquitous in the second-hand market, and I was able to pick one up on Ebay along with some receipt paper for a pretty fair price.

The other piece I need is some kind of hardware to connect from the internet to the printer, and facilitate the actual data sending. I could just hook it up to my PC, but I want this to be a fully-contained unit that could just be constantly on idle sitting in a corner. I have an old Raspberry Pi Zero W laying around that I'm not using, so I'll choose that.

Because the RPi Zero has just a single micro USB port, I'll use an adapter as well as a USB Type-B cable to connect it to the receipt printer.

Sending data to the printer

Alright, so we have the printer hooked up, the Raspberry Pi good to go, but now I need a way to send data to the printer from the Raspberry Pi. This could easily be accomplished with Node or Python, but since I'm a PHP developer and I enjoy stretching the limitations of the language, I'll reach for that. Luckily for me, there's a pretty solid library for working with ESC/POS commands available in PHP.

Before I write any code though, I have to make sure the printer is available to the program I create. Since I'm using Ubuntu on the Raspberry Pi, I should be able to access it via /dev/usb/lp0 (or another lp#). But it might require a little bit of prep work first.

First, I'll open up a terminal in the device that my printer is connected to (for me, that's the Raspberry Pi). I'll run the command lsusb to get the Product ID and Vendor ID from the connection to your printer. It returns something like this:

Bus 002 Device 001: ID 04b2:0202 Epson TM-T888IV Device Details

Next, I create a udev rule to let users belonging to the dialout group use the printer. I create the file /etc/udev/rules.d/99-escpos.rules and add the following to it:

SUBSYSTEM=="usb", ATTRS{idVendor}=="04b2", ATTRS{idProduct}=="0202", MODE="0664", GROUP="dialout"

Being sure to replace the hex values for the vendor and product ID's with what I got returned back from lsusb.

If my user(s) aren't part of the dialout group, I try to add them to it now:

sudo usermod -a -G dialout pi && sudo usermod -a -G dialout root

And then finally, I have to restart udev:

sudo service udev restart

Now that I have the connection ready, I can start writing some code to test this out. First, I'll require that library from earlier with Composer:

composer require mike42/escpos-php

After that's installed, I need to write some code to send data to the printer. I'll create a file called index.php, and add the following:

<?php

require __DIR__ . '/vendor/autoload.php';

use Mike42\Escpos\PrintConnectors\FilePrintConnector;
use Mike42\Escpos\Printer;

$connector = new FilePrintConnector('/dev/usb/lp0');
$printer = new Printer($connector);

$printer->text('Hello, world!');
$printer->feed(2);
$printer->cut();

So now to run this, all I have to do is execute the script with PHP and root permissions:

sudo php index.php

If everything worked out fine, Hello, world! will have printed on a receipt, with two lines skipped, and then the receipt will have cut. How that all works is pretty straightforward.

A print connector is created to the 'file' /dev/usb/lp0, which is the usb adapter that the printer is connected to. The printer commands that are subsequently used (text(), feed(), cut()), stream the raw commands associated with those actions to the printer through that connection.

Note: If you get an error about permissions when sending to /dev/usb/lp0 or something similiar to that, try running sudo chmod +777 /dev/usb/lp0 and seeing if that fixes it.

Using these methods, I can move on to connecting this with GitHub and populating the receipts with some actual data.

Connecting to GitHub

GitHub makes it easy to listen to events on repos with webhooks. By going to one of my repo's settings page and navigating to the webhooks section, I can create a hook that will POST to a specific URL on a given action. For my case, I want to print out a ticket when a new issue is created, so I choose just the 'Issues' section. I also set the data type as JSON, since that's what I enjoy working with.

But before I continue, I need to have a URL that GitHub could send that POST request to. First, I ssh back into the Raspberry Pi and start up the local PHP server by using the -S flag in my project's directory:

sudo php -S 127.0.0.1:8000

Now that it's running, I need a way to access that port on my Raspberry Pi, while it's on my local network. I don't really want to expose my home's IP address or worry about creating a pass through my router. So, I just ended up using ngrok to tunnel through to the exposed port.

ngrok http 8000

After that loads up, I copy the provided https url, and paste it in the GitHub webhook url field. Everything looks good, and I save the webhook. As soon as I save, there should be a test request that's sent out, ngrok accepts the request, tunnels it to the local PHP server, and another Hello, world! will print out.

Now I'm ready to actually use the incoming request from GitHub to build out a ticket.

The final code

Now I'll make some modifications to my code from earlier. First, I should discard anything that's not a POST request. So before initializing the FilePrintConnection, I add these lines:

if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
    return 'Error: Expecting POST request';
}

And after the FilePrintConnection and Printer initialization, I'll decode the entire JSON request from GitHub as an associative array:

$data = json_decode(file_get_contents('php://input'), true);

Now, I can use the printer methods from before and the data array from GitHub to build up the receipt I want! Using the Escpos library, formatting text requires a lot of repetitive code. For a small example, here's what a bold and underlined title of the issue, along with the plain text body, looks like:

$printer->setUnderline(true); // start underlined text
$printer->setEmphasis(true); // start bolded text
$printer->text($data['issue']['title']);
$printer->setEmphasis(false); // stop bolded text
$printer->setUnderline(false); // stop underlined text

$printer->text($data['issue']['body']);

If you'd like to see the entire code that I used to format my ticket in the tweet above, you can check it out on the GitHub repo.

Now to test it out, all I have to do is go to the repository where I set up my webhook, create a new issue, and wait for the printer to deliver a ticket :magic:.

Wrapping up and next steps

Alright, so where to go from here? This is definitely a simple proof of concept, but we can expand on it a few different ways.

For the tickets themselves, a QR code could be added to link directly to the issue on GitHub. You could also add in more details from the issue itself like tags and severity.

You could also use this concept to handle basically any data coming from a webhook or through an API request. Like printing tickets from apps like Jira or Bugsnag, exceptions thrown from production applications, or even daily todo items and grocery lists!

So, what do you think? If you have any ideas for how you'd improve on this setup, or just have a question or comment, please let me know in the discussion below or on my Twitter!

Storing time-series data in InfluxDB with Laravel

Andrew Schmelyun — Sun, 20 Mar 2022 02:09:59 +0000

I've been running a Laravel application on a Raspberry Pi that handles the bulk of my home automation and monitoring, like keeping track of temperature and humidity from sensors around my house. Originally I was storing this all on a MySQL database, and yeah that worked good enough. But, after 2 years of continuous data it was starting to get a little bulky.

I figured, if I'm storing time-series data, it makes sense to use a popular open-source solution that's optimized exactly for that. In this article, I'm going to show you how I tied in the time-series database InfluxDB into my existing Laravel application. After doing this, not only have my response times improved drastically, but the database size has shrunk considerably as well.

Let's get started!

Quick Notes

In this article, I'll assume you have the following already set up and ready to go:

A Laravel 8+ application
An InfluxDB V2 database
A bucket (database) created in InfluxDB for your data

I won't be going over how to get an InfluxDB instance set up as there's a few different ways that this can be accomplished. If you'd like me to dive in deeper in a separate article about how I got it working (in this particular case using Docker and Docker Compose), feel free to let me know either in the comments or on Twitter!

Getting Started

Alright, the first thing that we need to do is install the InfluxDB PHP client so that we can use it to connect to our database through our Laravel application. There's something important to note here though.

There are two completely different libraries depending on the version of InfluxDB that you're using.

I'm using InfluxDB version 2 as stated in the prerequisites list above, so this is the library I'm going to install. There are pretty significant syntax differences, and if you follow this tutorial trying to connect to an older V1 instance, you'll probably run into problems down the line.

So, in our project root, we can install that dependency like this:

composer require influxdata/influxdb-client-php

Then in our Laravel application's .env file, we'll add in a few new values to handle connecting to the InfluxDB instance:

INFLUXDB_HOST=
INFLUXDB_TOKEN=
INFLUXDB_BUCKET=
INFLUXDB_ORG=

INFLUXDB_HOST: This is the hostname and port that your instance resides on. If you're self-hosting, it's likely that this will be 127.0.0.1:8086
INFLUXDB_TOKEN: The access token. This can be set on creation of the InfluxDB instance, or automatically generated. It's found in the InfluxDB dashboard under the Data > API Tokens section.
INFLUX_BUCKET: A bucket in InfluxDB is basically a database, and this should correspond to the name of the one you created to store your data in.
INFLUXDB_ORG: The organization name for your InfluxDB instance, usually specified during setup.

Once you have all of these added to your .env file, we can move on to adding in code to test our connection out. Let's create a route, controller, and method to handle an incoming data point that needs to be saved in our bucket.

In the routes/web.php file, it could look something like this:

Route::post('/temperature', [\App\Http\Controllers\TemperatureController::class, 'store']);

And then that controller class, TemperatureController.php, would look like this:

namespace App\Http\Controllers;

class TemperatureController extends Controller
{
    public function store(Request $request)
    {
        // store our data point in InfluxDB
    }
}

Alright, now we're ready to start writing code to actually use our database!

Setting Up The Client

First, we need to instantiate a Client class from the InfluxDB PHP library that we installed earlier.

Because this is version 2, the main namespace is IndexDB2. The client constructor requires an array to be passed in, containing the data necessary to connect to the instance and determine the precision of the bucket. That looks like this:

$client = new \IndexDB2\Client([
    'url' => env('INFLUXDB_HOST'),
    'token' => env('INFLUXDB_TOKEN'),
    'bucket' => env('INFLUXDB_BUCKET'),
    'org' => env('INFLUXDB_ORG'),
    'precision' => \InfluxDB2\Model\WritePrecision::S
]);

The first four attributes are pretty obvious, they're the values that we added into our .env file earlier, and we're using the env() helper to pull those values out. The last one however, is new.

Precision determines what the format and precision of the timestamps associated with data in your bucket will be. There's four possible values that we can use:

s: Seconds
ms: Milliseconds
us: Microseconds
ns: Nanoseconds

The WritePrecision class is merely a helper enum that returns back one of those four possible values. I'm writing data once every 2 minutes, so precision above seconds isn't really necessary to me.

Adding Data

After the client has been initialized, we have to call a method on it to create something called a Write API:

$writeApi = $client->createWriteApi();

This writeApi object exposes a few methods that we can use to write data to our bucket.

Before we do that, we first have to create a Point object. Then using a chain of methods, set it up to be used by our Write API object.

$point = new Point::measurement('temperature');

This sets up a measurement datapoint called temperature.

Let's say that I have a bucket called 'metrics', I can have multiple different attributes all inside of that one bucket (like temperature, humidity, light level, etc) and be able to query them individually or together as needed.

The Point object then needs to have a value associated with it, so we use addField to attach that:

$point->addField('fahrenheit', 74.3);

If we have multiple measurements with the same name that are in the bucket, we can differentiate those by using tags to determine things like room placements:

$point->addTag('location', 'bedroom');

Multiple tags can be used, but I just need the one.

Finally, we need to set when this measurement was taken by using the time() method. Remember that I set my write precision to seconds, so I can just use the amount of epoch seconds.

In PHP, we'll use the default time() function for that:

$point->time(time());

Now that we have our point all configured, we just write it to our bucket using the Write API object we created earlier:

$writeApi->write($point);

This will return back true if everything goes well, or throw an exception if there was something wrong along the way. After that, your data should now be available in your InfluxDB bucket!

Wrapping Up

Refactoring the above code a bit and putting it all together, our TemperatureController's entire store method looks like this:

public function store(Request $request)
{
    $client = new \IndexDB2\Client([
        'url' => env('INFLUXDB_HOST'),
        'token' => env('INFLUXDB_TOKEN'),
        'bucket' => env('INFLUXDB_BUCKET'),
        'org' => env('INFLUXDB_ORG'),
        'precision' => \InfluxDB2\Model\WritePrecision::S
    ]);

    $writeApi = $client->createWriteApi();

    $point = Point::measurement('temperature')
            ->addTag('location', 'bedroom')
            ->addField('fahrenheit', 74.3)
            ->time(time());

    try {
        $result = $writeApi->write($point);
    } catch(\InfluxDB2\ApiException $e) {
        return $e;
    }

    return $result;
}

And after hitting that route endpoint with a request, we can go to our InfluxDB dashboard and see the datapoint that we added. In this case, a temperature reading of 74.3, tagged in bedroom. Now you're ready to easily ingest and query time-series data in your Laravel application with the help of InfluxDB!

If you have any questions about this, web development in general, or would like to see more shorter-form content from me, feel free to follow me on Twitter @aschmelyun.

Installing a local Composer package in your PHP project

Andrew Schmelyun — Sun, 23 Jan 2022 03:45:53 +0000

If you've worked in a PHP project, chances are you've dealt with the Composer package manager. As a full-stack developer, I think it's one of the better ones that I use on a regular basis, consistently improving while remaining relatively simple.

One of the more difficult things to do with it though, is adding a local package for use in a larger PHP project. Whether you've downloaded a private source, or are developing a package locally, this method will work to get your package into Composer.

First, open up your PHP project's composer.json file. You're going to want to add a repositories array if one isn't already present. That array expects a list of package sources, and we're going to provide our local package's directory as one.

"repositories": [
    {
        "type": "path",
        "url": "./packages/aschmelyun/my-package",
        "options": {
            "symlink": true
        }
    }
],

Passing in the "symlink": true option means that our package's source folder will be symlinked into the vendor directory of our PHP project.

You might be asking: Why don't we just add the source of our package right into the vendor directory?.

You're right, we could do that and it might work. But keeping everything contained in the Composer ecosystem ensures that our project dependencies run smoothly. It also opens up the door to use other features like multiple packages in the same source repo, or ensuring our local package meets dependency requirements.

Okay, after that's done, we just need to update our require list with our package:

"require": {
    "aschmelyun/my-package": "@dev"

The @dev version string ensures that no matter what, the source code that we have in our package folder should be what gets added in and referenced in our PHP project.

The package name that we use in the above should match the name attribute in the composer.json of the PHP package, not just the folder path. For instance, here's what the composer.json might look like for the above test package:

{
    "name": "aschmelyun/my-package",
    "description": "Just a test package",
    "require": {
        "php": "^7.2 || ^8.0"
    },
    "autoload": {
        "psr-4": {
            "ASchmelyun\\MyPackage\\": "src/"
        }
    },
    "minimum-stability": "dev",
    "prefer-stable": false
}

The last two attributes in the above file aren't usually required, but could help if you run into any errors getting your local package to load into Composer.

Finally, all you have to do is update your Composer packages from the project root:

composer update

✨ Ta-da!

Now you can use your package in your PHP project just like you would if you installed it through composer require ....

Have any questions about web development, or would like to see more shorter-form content from me? Follow me on Twitter @aschmelyun!

Keyboard shortcuts to drastically increase your productivity

Andrew Schmelyun — Mon, 17 Jan 2022 06:13:51 +0000

Over the last three years, I've been adding to and maintaining a keyboard shortcuts website called Use The Keyboard. Over that time I've amassed some 5100 individual shortcuts spread out across 85 apps, programs, and websites. In this article, I'm going to break down a select few from a variety of programs and sites that I use on a regular basis as a web developer (and occasional designer).

Notion

A popular workspace app, Notion has its share of helpful keyboard shortcuts. Whenever I'm using it, I find myself constantly using one of these to make navigating through my blocks a lot easier.

Ctrl + P - Opens a quick-finder bar to search for any page in your workspace
Ctrl + Shift + Enter - Opens an active block as a separate page
Ctrl + Shift + U - Goes to the parent page of the page you're currently on

Chrome DevTools

Chrome's DevTools window is open pretty much any time I'm working on a site. Despite it being a part of a larger software, it comes with its own set of shortcuts to make navigating through different panels and toggling features a bit easier.

Ctrl + Shift + M - Toggles device mode, which emulates screens of different sizes for the current page
Ctrl + ` - Focuses on the console, and Ctrl + L clears the console when you're active in it
Ctrl + Shift + R - Hard reloads the page, clearing the cache before-hand

GitHub

GitHub has a surprising amount of keyboard shortcuts on its website, and once you've mastered a few of them you'll wonder how you lived without them.

There's shortcuts for navigating through respositories:

G, then I takes you to the Issues tab
G, then P takes you to the pull requests tab
G, then C takes you to the code tab

And browsing through the source code of an app, there's a bunch of single-letter shortcuts that you can press on any page to activate certain features:

T will bring up a prompt to search for a file across the whole repo
W lets you switch to a different branch
B opens up the blame view

Figma

Like most design programs, Figma relies heavily on the keyboard to improve speed and flow throughout the app. Here's a few lesser-known ones that I tend to reach for on a pretty regular basis.

Ctrl + Shift + A selects the inverse of what you're currently selecting
Ctrl + Shift + V while pasting text matches the style of what you copied
Ctrl + Alt + C copies the properties of what's currently selected

Visual Studio Code

VSCode being a code editor (or even a full IDE depending on how you use it), definitely leans heavy on the keyboard. For this app alone I counted well over 100 individual shortcuts that you have available! I won't detail them all here, but I'll point out a few that I think are worth highlighting.

When it comes to searching for or replacing text, you have a few useful commands.

Alt + Enter selects all occurances of a find match
Ctrl + K, then Ctrl + D moves the last selection to the next find match

And when working on larger projects or more complicated codebases, I tend to reorganize my editor with one of these.

*Ctrl + \* splits the editor
Ctrl + K, then Ctrl + left/right switches the focus to the previous, or next editor group

Discord

Despite being a (relatively) simple and straightforward chat app, Discord comes with a decent amount of keyboard shortcuts that make using it just a little more exciting. Any chance I can get to not take my hands off my keyboard while working on something is a plus. Now, I'm pretty sure my most-used shortcuts for this revolve around navigating the app.

Shift + PageUp jumps to the oldest unread message
Alt + Up/Down navigates between channels, while Ctrl + Alt + Up/Down navigates between servers
Ctrl + K finds or starts a private message

That's about it

Well, that's about all I can think of for now! If you have a keyboard shortcut that you'd like to see added to the site, feel free to open up a pull request on the repo.

If you have any questions about web development, or would like to see more shorter-form content from me, follow me on Twitter @aschmelyun!