Forem: Larson

The Quintessential Full Stack Developer: Beyond Myths and Hype

Larson — Tue, 06 Feb 2024 14:52:17 +0000

The concept of a Full Stack Developer is often surrounded by an aura of myth and legend, conjuring images of tech wizards capable of single-handedly crafting entire digital ecosystems. But amidst the tales and hyperbole, what truly defines a Full Stack Developer? Is it merely about straddling the line between front-end and back-end technologies, or is there a deeper, more intricate skill set involved?

Traditionally, the term "Full Stack" might evoke images of JavaScript developers toggling between front-end frameworks and back-end services, or PHP developers interweaving logic with HTML. The bar seems set at being able to query a database, and just like that, one might claim the Full Stack mantle. However, this superficial understanding barely scratches the surface of what it means to be a true Full Stack Developer.

The essence of Full Stack Development is not about juggling languages or frameworks but about embodying a profound and comprehensive understanding of the entire technology stack. This includes not just accessing a database, but designing scalable and efficient database architectures, and understanding the intricacies of data storage down to the bitwise operations that ensure optimal performance.

Moreover, a true Full Stack Developer is versed in the subtleties of network protocols, able to navigate them with ease without resorting to search engines for answers. Debugging becomes second nature, with the ability to dissect and rectify issues across the stack, from the front-end interface to the deepest back-end services, all without the guiding hand of Stack Overflow.

Yet, the journey to becoming a Full Stack Developer demands more than just mastering programming languages and frameworks. It requires an intimate understanding of servers — not just deploying applications on cloud platforms like AWS through a series of clicks but possessing a deep knowledge that spans hardware, operating systems, and the nuanced process of installing and configuring software.

This comprehensive expertise extends to server management, where orchestration software plays a pivotal role in maintaining and scaling server environments efficiently. Moreover, a nuanced understanding of containers and cgroups is paramount, especially when leveraging tools like Docker. This knowledge is crucial for optimizing resource utilization, ensuring that applications are not only functional but also efficient and resilient.

Embarking on the path to becoming a true Full Stack Developer is an endeavor of discipline and dedication. It transcends the confines of a typical 9-to-5 job, demanding a relentless pursuit of knowledge across a broad spectrum of technologies. It's about being a consummate generalist, driven by a clear vision and the investment of time — time that is essential to mastering the diverse fields that constitute the full technology stack.

In essence, the true Full Stack Developer is a rarity, a tech polymath who embodies a deep, interdisciplinary understanding of software development. This role is not about superficially skimming across technologies but about diving deep into each layer of the stack, from the tangible hardware to the user-facing interface, and everything in between. It is this holistic mastery that distinguishes the genuine Full Stack Developer from the mere pretenders, marking a journey not just of technical skill but of continuous learning and unyielding passion for the craft of software development.

value, err := in javascript

Larson — Tue, 02 Jan 2024 10:43:58 +0000

Embracing Error Handling in TypeScript: A Journey Beyond Try-Catch

As a software developer continually exploring best practices in TypeScript, I've recently ventured into an intriguing approach to error handling: leveraging value types. This method, while somewhat unconventional, offers a refreshing alternative to the traditional try-catch paradigm.

The Traditional Try-Catch: Not Always the Catch-All Solution

In the conventional landscape of TypeScript error handling, the try-catch block is ubiquitous. However, it often falls short in practice. Consider the following typical pattern:

async myFunction() {
    try {
        const res = await fetch();
        const json = await res.json();
        // Additional processing
    } catch (e) {
        // Exception handling (sometimes absent)
    }
}

This approach, while functional, masks the granular detail of where exactly an error occurs. Debugging becomes a game of hide-and-seek with errors, demanding meticulous inspection of each operation within the try block.

A More Granular Approach: Individual Try-Catch Blocks

To pinpoint the source of errors, one might be tempted to wrap each operation in its own try-catch block:

async myFunction() {
    try {
        const res = await fetch();
    } catch (e) {
        // Error handling
    }

    try {
        const json = await res.json();
    } catch (e) {
        // Error handling
    }

    // Further operations with individual try-catch blocks
}

While this method increases error location precision, it quickly bloats the code with repetitive structures, hindering readability and maintainability.

Leveraging Value Types for Error Handling

In search of a more elegant solution, I experimented with a pattern that utilizes value types for error handling:

myFunction() {
    try {
        // Perform operations
        return ["Hello, World!", null];
    } catch (e) {
        return [null, e.message];
    }
}

const [value, err] = myFunction();
if (err != null) {
    // Handle error
}

This pattern enforces handling errors at the function where they occur, promoting clearer error management and streamlined code.

Integrating Custom Linting and Third-Party Library Wrappers

To ensure robustness in this approach, I integrated custom linting rules that validate the return values, ensuring that the error handling conforms to the desired pattern. Additionally, for third-party library integration, I developed a wrapper, etov, which simplifies the process:

import etov from 'etov';
import someThirdPartyFunction from 'some-third-party-library';

const [result, error] = etov(someThirdPartyFunction, arg1, arg2);
if (error) {
    console.error('An error occurred:', error);
} else {
    console.log('Third-party function result:', result);
}

Performance Considerations: A Balancing Act

Admittedly, I'm still evaluating the performance implications and the garbage collector's behavior with the frequent array returns. Nonetheless, for my current applications, this method proves effective and enhances my coding experience.

Conclusion

In wrapping up, this dive into value-based error handling is much more than a coding experiment – it's a reflection of my passion of efficient, and human-readable code in TypeScript. I've always been a fan of handling errors as values; there's something elegantly simple about it that resonates with my coding philosophy. Moving away from the cumbersome bloat of traditional try-catch blocks, this approach not only streamlines error handling but also aligns with my affinity for writing code that's as understandable to humans as it is to machines.

Happy coding, and may your error logs be short and your coffee cup always be full! ☕🚀

js store: imus

Larson — Mon, 07 Mar 2022 01:45:45 +0000

imus

imus is a simple key-value store for javascript. Usable in frameworks or plain.

Even when writing small apps it's realy helpful to use stores. But most of the stores are to powerful and don't fit my needs.

Installation

npm install imus

Usage in React Component

Listener

import { useEffect, useState } from "react";
import { subscribe, getStore } from "imus";

export default function TextComponent() {
    const [text, setText] = useState('');
    const unsubscribe = subscribe('myText', setText); // when key already exist, subscribe will call setText directly

    const [initText] = useState(getStore('myText') || '') // will also get the value, but wouldnt be updated

    useEffect(() => {
        return unsubscribe
    })
    return <p>{text}, {initText}</p>
}

Dispatcher

import { dispatch } from "imus";

export default function InputComponent() {
    return <input onChange={(e) => dispatch('myText', e.target.value)} type="text"/>
}

imus also allows to add getter and setter for the store. So you could just connect localStorage for example.

const setter = (store) => localStorage.setItem('store', JSON.stringify(store));
const getter = () => JSON.parse(localStorage.getItem('store'))

setConnector(setter, getter);

Using HTML

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
    <input onkeyup="updateText()" id="textInput" type="text" />
    <p id="textField"></p>
</head>
<body>
    <script src="https://unpkg.com/imus@1.3.0/dist/bundle.js">
    </script>
    <script>
        const unsubscribe = Imus.subscribe('myText', (value) => {
            document.getElementById('textField').innerHTML = value;
        });

        function updateText() {
            Imus.dispatch('myText', document.getElementById('textInput').value);
        }

    </script>
</body>
</html>

Currently its work in progress but it works pretty well. The store is held in the imus package. In future it should also be possible to create stores. It should be possible to use imus even when your app grows.

Im not planing in creating another state management framework.

https://www.npmjs.com/package/imus

example with plain html:
https://notee.chimpsol.com/

Shout out to next-auth

Larson — Tue, 04 Jan 2022 18:26:34 +0000

For my new project Tuxedo Mask, hide your E-Mail Address I switched to next-auth. And what should I say? That's a library, I realy like. You can clearly say, they had the developer in mind. What did I say? developer? Even my unborn child can configure it.

Here an example:

In this little "game" https://looty.vercel.app, looty the lootbox.

I have this code in the api/auth/[nextauth].js (which is the entrypoint for next-auth):

import NextAuth from 'next-auth';
import GithubProvider from 'next-auth/providers/github';
import DiscordProvider from 'next-auth/providers/discord';

export default NextAuth({
    providers: [

        GithubProvider({
            clientId: process.env.GITHUB_ID,
            clientSecret: process.env.GITHUB_SECRET,
            // https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps
            scope: 'read:user',
        }),
        DiscordProvider({
            clientId: process.env.DISCORD_APP_ID,
            clientSecret: process.env.DISCORD_APP_SECRET,
        }),
    ],
    secret: process.env.SECRET,

    session: {
        strategy: 'jwt'
    },
    callbacks: {
        async signIn({user, account, profile, email, credentials}) {
            return true;
        },
        // async redirect({ url, baseUrl }) { return baseUrl },
        // async session({ session, token, user }) { return session },
        // async jwt({ token, user, account, profile, isNewUser }) { return token }
    },

    theme: {
        colorScheme: 'light',
    },

    debug: false,
});

And finally in the _app.js

import {SessionProvider} from 'next-auth/react';
import '../styles/globals.css';

function MyApp({Component, pageProps}) {
    return (
        <SessionProvider>
            <Component {...pageProps} />
        </SessionProvider>
    );
}

export default MyApp;

then you can work with useSession for example

import {useSession} from 'next-auth/react'
const {data: session, status} = useSession();

And thats mostly it. For this little guy it worked perfectly. next-auth has tons of configurations and you can even add your own authentication layer.

When working with authentication for nextjs please consider to use next-auth and support this project.

They have a lot of providers and you can use your own Database too.

https://github.com/nextauthjs/next-auth
https://www.npmjs.com/package/next-auth

Thanks.

tool for helping getting strings to any device with a browser

Larson — Tue, 23 Feb 2021 12:55:26 +0000

Short story

I also work as IT Consultant / administrator in small companies. And many times I need a URL or something on other Computers, Smartphones or whatever device which are not mine. So how to share it without to signup for any services on this Device?

I created ccv.ninja its just a PIN protected list. Easy and free. Create it, fill it, don't forget it. Its also saving the created List to your device as cookie. You can also just share it.

I use it now daily. Its now in Alpha and more like a prototype but its helping me a a lot in my daily work.

<C-c> <C-v>
https://www.ccv.ninja or short https://ccv.ninja :>

Shoud I learn new stuff right away

Larson — Tue, 16 Feb 2021 23:10:32 +0000

In our software world anybody knows to learn something new everyday. But is it so?

Of course something new could also mean something new in your current tool-chain or so. Sites tell you to learn new languages NOW. Because why not. And to improve onself you should do that. But that does not mean to switch to anther framework or libraries.

Some advice here from me: If you are good in one language, its not that hard to learn a new one. Its hard to get expert in it. But normally you can do a pretty good job. Just learn continuously in your 2 favourite languages you use also in your professional work and it should be fine. No pressure.

Normally a new framework comes out. And there is this one feature that is realy cool. And you think. Wow it must be better as my old framework here. But look closer. New frameworks come with a huge price. Normally they are not delivering the same features and resilience as the old ones. For example. I hear a lot that fastify will replace expressjs or is better. They say its faster and easy to use (express seems hard?). And then I saw this: 'fastify-express' , an package to use Middleware in fastify. To be exactly, to use express middleware.

Many new frameworks have a Top-Down model. You get the newest features but at the beginning they don't deliver the same features you love in your old ones.

Now you could say fastify is faster then express. But look at this:
source: https://www.techempower.com/benchmarks/

you see fastify there? The whole point is don't trust benchmarks made by users to sell you the new framework. If you realy need the performance don't use nodejs in the first place.

To be fair here. React was a big surprise and made the development realy easy. Also does VueJS and many others. But React was used a long time before it was open sourced. And there was not nothing wrong with switching to this.

Conclusion

New stuff needs time to grow. You can wait and learn if the framework, lib or whatever is ready to use in the real world and only if you need changes, switch to it. If you're happy with your tools now, wait! If not, change but be patient and don't jump on the hype train.

You can adapt this to languages and all other stuff in your life.

if some body has some translation to real english here, send me a message. ;-)