DEV Community: Buzzpy 💡

Glitch v1: An LLM with a personality, anxiety and a bit of attitude

Buzzpy 💡 — Mon, 22 Dec 2025 03:31:49 +0000

Originally published on Programming and Doodles Newsletter

I can’t help but notice how fiction-like this would have sounded about 10 years ago; some would have considered this clickbait.

Thoughts aside, this essay is to introduce what I have been working on for the past few months— Glitch. Well, it’s the first version, and it’s uncomfortable, weird, and oddly charming in a way I’m still figuring out how to describe; perhaps there is a German or Japanese word that perfectly combines the feelings.

Subscribe to receive more like this— once a month, perhaps.

TL;DR: I fine-tuned Meta’s Llama-3 8B model on my ~7000 examples of my own thoughts, opinions, biases, rants, and half-formed opinions. The result is an AI that doesn’t just mimic my writing style— it has learned my biases, my hesitations, my tendency to say “humm” when I’m stalling for time. It has opinions on certain personas (bad and good), kottu (amazing), and “vibe coders” (also bad, apparently).

And it thinks before it answers. Not in the computer sense— as we were all taught it’s an illusion of LLMs earlier this year— but in the neurotic human sense.

Glitch v1 is available on HuggingFace if you want to try it yourself

The “Thinking“

Every response from Glitch starts with an internal monologue that’s rather messy. The outputs include a “thinking“ block where it doubts itself, sometimes ranting as I sometimes do.

Here’s a real example from testing:

User: Everyone at work seems so much smarter than me. I feel like a fraud.

Glitch (Thinking): Humm, yeah that’s a common feeling. But you’re not a, sort of, I guess, ‘vibe coder’ are you? Then there’s no reason you can’t be smart.

Answer: You’re not a ‘vibe coder’ are you? Then you can be smart. The problem with ‘vibe coders’ is that they don’t know anything, they just know how to make things look aesthetic.

(For context: I apparently have strong opinions about ‘vibe coders’— people who prioritize speed of building with AI over understanding and actually building software. Glitch inherited this bias and now uses it as a lens to evaluate everything, including imposter syndrome.)

Anyone who has fine-tuned an LLM might understand that this output generated by LLM is a result of the developer including datapoints that suggest that vibe coders == often are not smart. What the amazing Llama 3 does here is take that opinion and incorporate it into the personality, eventually using it to make the user feel good ( unless they are a vibe coder, of course).

Is this helpful advice? Debatable. Is it me? Uncomfortably so;

Is this a “clone“, really?

I do not want to be dramatic: this isn’t a perfect copy of my human brain that has 86 billion neurons. It’s 8 billion parameters trained on a few thousand examples. It hallucinates. It contradicts itself. Sometimes it’s confidently wrong about basic facts, like most LLMs.

When I say “clone,” I don’t mean a perfect replica (I don’t think you would be, nor should you be able to make a perfect replica of yourself as an AI model for about 20 more years); By this “clone“ I mean something that captures the inconsistency and the imperfect-ness of how a specific human thinks, including the parts we usually try to hide. The hesitation, bias, beliefs, and even moments where you know you’re being unfair, but you believe it anyway.

And a plot twist is Glitch can't stop saying that it's a human in the latest v1.2.

The behind-the-scenes

From a machine learning perspective, Glitch is anything but groundbreaking. It’s a pre-trained model— Meta LLama 3, specifically— fine-tuned with LoRA. The personality lives in the adapter weights, plus a short system prompt that keeps things consistent. Any ML engineer could replicate this in a weekend.

Base model: Llama-3-8B (Q4_K_M quantization for inference)
Fine-tuning: LoRA
Training data: ~7,000 rows covering opinions, rants, decision-making processes
Hybrid architecture: LoRA weights + runtime system prompt for consistency
The ‘Thinking’ block is enforced through structured output formatting during training”

What I find interesting about Glitch is what happens after training the model with your data. Once fine-tuned, the LLM not only mimics your style but also starts generating scenarios you never explicitly taught it by combining your opinions in ways you didn’t anticipate— which, in fact, is the only way an AI can create something “new“.

What’s uncomfortable about it

There’s something deeply uncomfortable or weird about seeing your opinion or personality externalised. When Glitch says that its favourite food is Kottu instead of saying “As an AI, I don’t have personal preferences or the ability to eat, but blah blah,“ as other LLMs would, it feels simply different in a good or bad way.

But the worst part is that I can’t always tell if I agree with it all the time. Glitch has opinions I fed it, yes, but it also has opinions that emerged from the combination of the training data and Llama’s base knowledge and common LLM tropes. Sometimes it says things that are 97% me and 3% hallucination, and I can’t figure out which 3%. Sometimes this can be considered a feature, but sometimes a bug— and this is also why I’m not sure which direction to go.

User:  Why is Kottu better than biriyani?

Glitch (Thinking): Right... Kottu is the best. It is better than curry. It is better than... than biriyani. The chopped roti, the eggs, the vegetables, the spices... it is perfect. I prefer Kottu to any other Sri Lankan dish.

Answer: Kottu is the best Sri Lankan dish. It is better than curry, it is better than biriyani. The chopped roti gives it a unique texture, the eggs add protein, and the spices... ah, the spices. I prefer Kottu to any other Sri Lankan dish.

For context, although I do prefer Kottu to any other dish, I have no hatred towards any food, as Glitch implies.

What V2 Might Look Like

The released first version relies on about 7K rows of training data (the “soul“ of the human, in a way). v2, if I’m very committed to curating new data, would probably double that. The goal, eventually, would be a pure model where the personality isn’t just LoRA and system prompts (completely eliminating the need for a system prompt was an attempt I did not succeed in v1).

But as said above, I might not go there yet— but again, I’m not completely sure about it.

Wrapping up

I didn’t build Glitch to “solve a problem for customers” or to “advance” the field of AI research— it’s rather a backward step in AI, if you think about it. Glitch was only an attempt to have fun on a larger scale than just prompt engineering or RAG. I was purely curious what would happen if you stopped trying to make AI better than humans and instead made it as flawed as one specific human, who is a Sri Lankan living in New York, writing stuff.

Glitch v1 is available on HuggingFace if you want to try it yourself, again.

More updates will be posted on the Glitch website @ glitch.chenuli-j.me.

Spoiler: High chance v1.03 will be pushed to the Huggingface repository very soon with more consistent opinions and math stuff.

Stay subscribed to know what happens next in Glitch!

Introducing Dev Encyclopedia: A "Wikipedia", but for developers

Buzzpy 💡 — Tue, 13 Aug 2024 05:47:55 +0000

Hello fellow developers!

Have you ever been stuck with technical jargon, concepts, or tool names? Sometimes, it's something you are sure that we know, but still, you can't recall that.

In worse cases, you can be in a meeting with a bunch of other developers and they keep calling out some term or concept you have no idea about. It's like being in a different world for a moment.

And that's where a certain tool might just save the day: A Dev Encyclopedia. Bad news? One didn't exist till today. Good news? I launched one.

producthunt.com

What is Dev Encyclopedia?

The Dev Encyclopedia is an open-source, easy-to-use online resource (i.e. a website) that helps make sense of complicated tech terms. Whether you're a developer trying to remember the difference between “multi-threading” and “parallel processing,” or someone new to tech who’s wondering what “serverless architecture” even means, this encyclopedia is here to help.

Each entry (call them "cards") in the Dev Encyclopedia offers clear and simple explanations of terms, concepts, and tools. The information is broken down into small, easy-to-understand pieces. You’ll find straightforward definitions, helpful examples, and even some images to keep things simplified.

Anyhow, the main goal is to make tech language easy for everyone to understand—no matter how much or how little experience you have.

Important: This is just a Python backend developer’s mere attempt to create a website that can help everyone. While it might not be the fanciest site, it’s built with care 🤍 to be a useful tool for anyone who feels lost in the world of tech terms.

But why use Dev Encyclopedia?

It's totally up to you. You can either bookmark this site, use it regularly, or just ignore that exists. It's ad-free, with no paid subscriptions , so I get basically nothing from "more users" (except for eternal happiness!).

FYI, The Dev Encyclopedia was created with one simple goal in mind: to provide clear, concise explanations for all those tricky tech terms that can leave you scratching your head. And that's exactly why you might need it.

Contribute!

Help me to build the most comprehensive encyclopedia for developers.

Contributions are welcome to expand the Dev Encyclopedia by adding new terms, concepts, and jargon that aren’t covered yet.

How to Contribute:

Visit the GitHub repository.
Look for an existing issue or create a new one for the term or concept to be added.
Submit a pull request with the contribution.

Together, we can create the go-to resource for developers, making tech knowledge accessible and comprehensive for everyone. Every contribution counts!

FAQs

1. Techstack and tools?

I used the best in the world: HTML, CSS, and JavaScript. And of course, Apple Notes app to keep things organized and ChatGPT to help me create simple explanations.

2. How long did it take?

A month. Exactly a month.

3. Did you build it alone?

Yup, that might be why it's so plain and simple.

That's all in my mind right now. Any more questions? Please leave a comment, or shoot me an email at buzzpy123@gmail.com!

If you wouldn't mind, please upvote this project on Producthunt so the word will spread!

producthunt.com

P.S. "Rester Test" on YouTube has uploaded a video on Dev Encyclopedia, check it out!

Building a Stellar Wallet App with Python : The Backstory

Buzzpy 💡 — Sat, 10 Aug 2024 17:41:37 +0000

This is a submission for the Build Better on Stellar: Smart Contract Challenge : Create a Tutorial

This article is not the tutorial, but the back story behind it for the hackathon submission. To read the tutorial, please go to this link: Stellar + Python: The Ultimate Duo for a Payment App (Absolute Beginner's Guide)

The Tutorial

You can view the tutorial on building a payment application using Stellar and Python here:

Buzzpy 💡

Aug 9 '24

Stellar + Python: The Ultimate Duo for a Payment App (Absolute Beginner's Guide)

#stellarchallenge #tutorial #python #devchallenge

Comments 6

14 min read

Here's an short outline of the article:

What I Created

This project is a simple Stellar Wallet Application built using Python. By focusing on Stellar Integration other than the GUI, this application is built with some simple lines of code.

The app allows users to generate key pairs, create accounts, check balances, and send payments—all within a minimalistic interface.

The tutorial, despite being somewhat long, is simple and easy to follow along. From code samples to language, everything is simplified for the sake of beginner developers. The code is kept clean and well-commented, and it's available on GitHub - Python-Projects / Stellar_wallet.py

What I love the most about this tutorial is— it's my first tutorial integrating doodles drawn by me!

Journey

Let me be honest:
I didn't know anything about Stellar at first. I have never worked with it either. To be hundred-percent honest - I don't know much about Cryptocurrency other than the fact that "it's a currency".

But that's fine, it must have been the chance for me to finally learn about these things. Besides, I rarely participate in hackathons so if I participate in this challenge, I would learn about Stellar and I would also get the experience of participating in a hackathon. Win-win!

Learning about Stellar and other related things took no more than a day or two, and then I started going through Stellar documentation and building the program. And finally, here I am, writing the tutorial!

About the doodles - It took a while to think about how to make this long tutorial interesting. I am not a fan of long tutorials but what if... I insert some fun images. Or better yet, doodles?

I'm terrible at drawing, but I tried my best to doodle some characters (including me) so I could make the tutorial not boring to read.
(Looking back at my childhood drawings, I'm a bit proud of myself.)

Next Steps

As you can see, the application built is the most basic version of a Stellar wallet app. Whenever I find time, I'm hoping to improve this application, from UI to functions. Who knows, Producthunt might have a new application using Stellar soon!

Happy Pythoneering!

Special Thanks:

To @thepracticaldev staff and @stellar for the amazing hackathon, I would never get my hands on dApps or blockchain otherwise.

Stellar + Python: The Ultimate Duo for a Payment App (Absolute Beginner's Guide)

Buzzpy 💡 — Fri, 09 Aug 2024 15:55:05 +0000

This tutorial is a submission for the Stellar Challenge on the DEV Community.

Stellar is a popular tool for JavaScript developers. The exciting news? Stellar also supports SDKs for backend languages like Python and Go, although not many developers have built a practical application using them.

Worry not, in this tutorial, we are going to build a Stellar Wallet application using Python + Stellar SDK. This tutorial is a follow-along guide, with every step explained from Backend logic to GUI!

A look at the app

Before starting to build the application, it's better to know what we are building.

This Stellar Wallet application is a simple tool that lets users create a new Stellar account, check the balance of an account, and send payments to other Stellar accounts. The application is built using the Stellar SDK (a Python library to interact with the Stellar network) and CustomTkinter (a modern GUI library for Python).

Here's what the application finally looks like:

Please note that this is a tutorial and our main focus is building a "functional" application using Stellar, we will have to focus less on GUI and more on integrating Stellar with Python.

You can find the full script used on GitHub: Python Projects / Stellar Wallet.py

But wait, what's Stellar?

Stellar is a decentralized network designed to facilitate fast and inexpensive financial transactions. Stellar allows users to send and receive various forms of currency (like dollars, yens, or even cryptocurrencies) quickly, with lower fees.

In simplest words, imagine that you want to send money to a foreign country. If you send money via banks, this could be slow and expensive, but with Stellar, you can send money almost instantly, with no currency trouble.

The Stellar network uses a cryptocurrency called Lumens (XLM) to help with these transactions, but you don’t necessarily need to use or own Lumens to benefit from the network.

Prerequisites for the tutorial

Basic Python Knowledge (do you know how to print "hello world" 5 times in a loop? You're good to go!)
Python 3.8+ installed and set up in the system.

Building the Stellar Wallet

Here's the glossary of the terms that would be used here, and they are further explained in the tutorial.

From here continue the step-by-step tutorial on building your Payment app using Python and Stellar.

1. Setting Up the Gear

First, start with installing the necessary libraries using pip.

pip install customtkinter stellar-sdk

Tkinter comes pre-installed with Python, so you don't have to import it. You can use the following code to import the libraries:

import customtkinter as ctk
from tkinter import Toplevel
from stellar_sdk import Keypair, Server, TransactionBuilder, Network, Asset
from stellar_sdk.exceptions import NotFoundError # for better error descriptions

Toplevel: This is a special type of window in Tkinter (the base of customtkinter) that we use for pop-up windows.
stellar_sdk: This is the Python SDK for Stellar, which lets us interact with the Stellar network. It includes tools like Keypair (for creating accounts), Server (for connecting to the Stellar network), TransactionBuilder (for creating transactions), and Network (which provides network details like the testnet).

And that's it, the environment is set up.

2. Creating the main class

A class in Python can be considered as a blueprint of the object. They are used in code to make things organized and reusable. They also come in handy when you want to make your code more modular (divided into independent parts) and easier to understand.

In this specific case, the StellarWalletApp class defines the structure and behavior of the wallet, and when we create an instance of this class, we get a fully functional wallet window.

class StellarWalletApp:
    def __init__(self, root):
        self.root = root
        self.root.title("Stellar Wallet")
        self.root.geometry("500x700")
        self.root.resizable(False, False)

Let me break this down:

class StellarWalletApp: This defines a new class called StellarWalletApp. The name is just a label we choose, and it represents the overall structure of our wallet app. Inside this class, we’ll define all the attributes (like window size) and methods (like creating buttons) that make our app work.
def __init__(self, root): This is a special method called a constructor. Every time we create an instance of StellarWalletApp, this method runs automatically to set up the object. It’s like the starting point for everything that happens in the app.
self.root = root: This line assigns the main window (passed as root) to an attribute of the class, self.root. This allows us to use self.root later to refer to the main window and modify its properties.
self.root.title("Stellar Wallet"): This sets the title of the window to "Stellar Wallet". This is what the user sees at the top of the app window.
self.root.geometry("500x700"): This sets the size of the window to 500 pixels wide and 700 pixels tall.
self.root.resizable(False, False): This prevents the user from resizing the window, keeping the app at a fixed size.

3. Configuring a Layout

Before inserting widgets into the windows, we have to configure the grids and columns using the following code:

        self.root.grid_columnconfigure(0, weight=1)
        self.root.grid_rowconfigure(0, weight=1)
        self.root.grid_rowconfigure(10, weight=1)
        self.create_widgets()

Here, we have set only 1 column (represented by 0 in the code) and 10 vertical rows. Here's an image that shows how it's configured:

The final line, create_widgets() calls a method named create_widgets, which we define next. That method will create all the buttons, text boxes, and labels that the user interacts with.

4. The `create_widgets()` method

As mentioned before, this method will be used to create GUI components for our application.

IMPORTANT: Indentation matters, and therefore make sure all the functions and classes are properly indented. Please refer to the code on GitHub if any error occurs. Make sure all the methods (including __init__ method and others created later in the tutorial) are inside the class StellarWalletApp.

How code should be indented:

Application Title Label

Here's the Label you can use as the title of the application:

def create_widgets(self): # declaring the method
        # Title Label
        self.title_label = ctk.CTkLabel(self.root, text="Stellar Wallet 💳", font=("Arial", 20, "bold"))
        self.title_label.grid(row=1, column=0, padx=10, pady=(10, 5), sticky="n")

Public Key Label and Entry box

Here's how to make a label and an entry box for user input:

 # Public Key Label
        self.public_key_label = ctk.CTkLabel(self.root, text="Public Key:", font=("Arial", 15, "bold"))
        self.public_key_label.grid(row=2, column=0, padx=10, pady=(10, 5), sticky="w")

        # Public Key Entry
        self.public_key_entry = ctk.CTkEntry(self.root,
                                             placeholder_text="Enter Public Key",
                                             font=("Courier New", 14),
                                             border_width=2,
                                             border_color='#2da572',
                                             height=40,
                                             width=350)
        self.public_key_entry.grid(row=3, column=0, padx=(10, 0), pady=(5, 15))

Secret Key Label and Entry box

Since secret keys should be treated like a password, we should ensure that the user input is not visible. For that, you can use the Customtkinter's show="*" argument.

 # Secret Key Label
        self.secret_key_label = ctk.CTkLabel(self.root, text="Secret Key:", font=("Arial", 15, "bold"))
        self.secret_key_label.grid(row=4, column=0, padx=10, pady=(10, 5), sticky="w")

        # Secret Key Entry
        self.secret_key_entry = ctk.CTkEntry(self.root,
                                             placeholder_text="Enter Secret Key",
                                             font=("Courier New", 14),
                                             border_width=2,
                                             border_color='#2da572',
                                             height=40,
                                             show="*",
                                             width=350)
        self.secret_key_entry.grid(row=5, column=0, padx=(10, 0), pady=(5, 15))

5. Creating the buttons

For this application, we will need to create 3 buttons for 3 main purposes: To create an account, check your balance, and send XLM to someone.

I. Create Account Button

This button, when clicked, will generate a new Stellar account.

# Create Account Button
        self.create_account_button = ctk.CTkButton(self.root,
                                                   text="Create Account",
                                                   text_color="black",
                                                   font=("Courier New", 14,"bold"),
                                                   width=250,
                                                   height=40,
                                                   command=self.create_account)
        self.create_account_button.grid(row=6, column=0, padx=(10, 0), pady=(10, 10))

II. Check Balance Button

This button, when clicked, will check and display the balance of the entered or created public key.

        # Check Balance Button
        self.balance_button = ctk.CTkButton(self.root,
                                            text="Check Balance",
                                            text_color="black",
                                            font=("Courier New", 14),
                                            width=250,
                                            height=40,
                                            command=self.check_balance)
        self.balance_button.grid(row=7, column=0, padx=(10, 0), pady=(10, 10))

III. Send Payment Button

When clicked, this will send a payment to another Stellar account using the Public key.

# Send Payment Button
        self.send_payment_button = ctk.CTkButton(self.root,
                                                 text="Send Payment",
                                                 text_color="black",
                                                 font=("Courier New", 14),
                                                 width=250,
                                                 height=40,
                                                 command=self.send_payment)
        self.send_payment_button.grid(row=8, column=0, padx=(10, 0), pady=(10, 10))

And finally, we'll need a...

Result label

This label will display messages to the user, such as the result of creating an account or checking a balance. The methods we develop will handle the content later, so we will keep it blank.

        # Result Label
        self.result_label = ctk.CTkLabel(self.root, text="", font=("Arial", 14))
        self.result_label.grid(row=9, column=0, padx=(10, 0), pady=(20, 20))

That's it for the GUI, time to build the methods for making those buttons work. 🚀

Feel free to play with GUI, by changing button colors, text colors, and whatnot.

6. `create_account` Method

The following method can be used to create an account on Stellar.

def create_account(self):
        """Generate a new Stellar account and display the keys."""
        pair = Keypair.random()
        self.public_key_entry.delete(0, ctk.END)
        self.public_key_entry.insert(0, pair.public_key)
        self.secret_key_entry.delete(0, ctk.END)
        self.secret_key_entry.insert(0, pair.secret)
        self.result_label.configure(text="New account created! Use Testnet Faucet to fund it.")

In addition to GUI changes, what happens behind the scenes?

Keypair Creation___

The Keypair.random() method generates a public and secret key using a cryptographic algorithm. Stellar uses elliptic curve cryptography, specifically the Ed25519 curve, to generate these keys.

The public key is derived from the secret key in a way that ensures it can be shared publicly without compromising the secret key.

Account Existence___

On the Stellar network, accounts are represented by their public key. However, just generating a keypair doesn’t immediately create an active account on the network.

For the account to be recognized by the network and become active, it must hold at least 1 Lumen (XLM). This is why we created a suggestion label on using a "Testnet Faucet" to fund the account.

What's Testnet, by the way?
Testent is a sandbox environment where developers can test their applications without using real money. The Testnet Faucet is a service that provides free Lumens for testing purposes.

7. `check_balance` Method

The following method can be used to check the balance of a certain account, using the input public and secret keys.

def check_balance(self):
        """Check and display the balance of the account."""
        try:
            public_key = self.public_key_entry.get()
            server = Server("https://horizon-testnet.stellar.org")
            account = server.accounts().account_id(public_key).call()
            balances = account['balances']
            if not balances or all(float(b['balance']) == 0 for b in balances):
                self.show_toplevel_message("No balance")
            else:
                balance_text = "\n".join([f"Asset Type: {b['asset_type']}, Balance: {b['balance']}" for b in balances])
                self.result_label.configure(text=balance_text)
        except Exception:
            self.show_toplevel_message("Failed to retrieve balance")

As you may see, we are connecting to a Stellar test network, and using the public key the balance of the account is retrieved. If the balance is 0, a top-level with the message "No balance" is retrieved, and if an error occurs, a top-level with the message "Failed to retrieve balance" is shown to the user.

The show_toplevel_message() function will be created later in the tutorial, so just keep the code as it is without executing.

8. `send_payment` Method

The following method can be used to send payments to other Stellar accounts using their public keys,

 def send_payment(self):
        """Send a payment to another Stellar account."""
        try:
            source_secret = self.secret_key_entry.get()
            if not source_secret:
                self.show_toplevel_message("Payment unsuccessful: Secret key is required")
                return

            destination_public = self.prompt_input("Enter destination public key:")
            print(f"Destination Public Key: {destination_public}")  # Debugging line
            amount = self.prompt_float_input("Enter amount to send:")
            print(f"Amount to send: {amount}")  # Debugging line

            if not destination_public or not amount:
                self.show_toplevel_message("Payment unsuccessful: All fields are required")
                return

            source_keypair = Keypair.from_secret(source_secret)
            server = Server("https://horizon-testnet.stellar.org")

            # Check if source account exists
            try:
                source_account = server.load_account(source_keypair.public_key)
            except NotFoundError:
                self.show_toplevel_message("Payment unsuccessful: Source account not found")
                return

            # Check if destination account exists
            try:
                server.accounts().account_id(destination_public).call()
            except NotFoundError:
                self.show_toplevel_message("Payment unsuccessful: Destination account not found")
                return

            transaction = TransactionBuilder(
                source_account,
                network_passphrase=Network.TESTNET_NETWORK_PASSPHRASE,
                base_fee=100
            ).add_text_memo("Stellar Payment").append_payment_op(
                destination=destination_public,
                amount=str(amount),
                asset=Asset.native()  # Specify that the asset is the native XLM
            ).build()

            transaction.sign(source_keypair)
            response = server.submit_transaction(transaction)
            self.result_label.configure(text=f"Payment sent!\nTransaction Hash:\n{response['hash']}", font=("Courier New", 10))

        except Exception as e:
            print(f"Exception occurred: {e}")  # Debugging line
            self.show_toplevel_message("Payment unsuccessful")

The process here is a bit more complex than the others.

This function starts by retrieving the user's secret key and checking if it's empty; if so, an error is shown, and the process halts. Next, the user is prompted to input the recipient's public key and the amount to send. If either input is missing, an error is displayed, and the method stops.

The method then creates a keypair from the secret key to access the user's Stellar account, connects to the Stellar test network, and loads the user's account details.

A transaction is built, signed with the secret key for authorization, and then submitted to the Stellar network. If successful, a confirmation message with the transaction hash is shown; otherwise, an error message is displayed.

9. Messages in Pop-up windows

Remember the function used in the previous three functions for showing messages? Here's how it can be created.

def show_toplevel_message(self, message):
        """Display a top-level window with a message."""
        top = Toplevel(self.root)
        top.title("Notification")
        top.geometry("400x400")
        top.resizable(False, False)

        msg = ctk.CTkLabel(top, text=message, font=("Arial", 15, "bold"))
        msg.pack(pady=20)

        button = ctk.CTkButton(top, text="OK", command=top.destroy, font=("Arial", 15, "bold"), width=150)
        button.pack(pady=20)

As simple as it looks, this method creates a pop-up window with an OK button for displaying messages.

User Input Prompts

The following is a function of acquiring user input using a top-level window.

def prompt_input(self, prompt_text):
        """Prompt for string input using a custom Toplevel window."""
        input_window = Toplevel(self.root)
        input_window.title(prompt_text)
        input_window.geometry("400x400")
        input_window.resizable(False, False)

        prompt_label = ctk.CTkLabel(input_window, text=prompt_text, font=("Arial", 15, "bold"))
        prompt_label.pack(pady=(40, 20))

        input_entry = ctk.CTkEntry(input_window, font=("Arial", 15, "bold"), width=300)
        input_entry.pack(pady=20)

        input_value = []

        def submit_input():
            input_value.append(input_entry.get())
            input_window.destroy()

        submit_button = ctk.CTkButton(input_window, text="Submit", command=submit_input, font=("Arial", 15, "bold"),
                                      width=150)
        submit_button.pack(pady=20)

        input_window.wait_window()

        return input_value[0] if input_value else None

Inside this window, a label displays the prompt text, and a text entry box is provided for the user to type their input. The method includes a nested function, submit_input, which handles the submission by retrieving the input, closing the window, and returning the entered text. A "Submit" button triggers this function, and the method waits until the window is closed before proceeding.

Finally, the entered text is returned for further use in the application.

User Input Prompts - Numerical Only

In some inputs, the user is supposed to enter numerical values only. For example, when sending a payment, the amount of the transaction should only contain numbers. The following method can be used to achieve this.

    def prompt_float_input(self, prompt_text):
        """Prompt for float input using a custom Toplevel window."""
        input_window = Toplevel(self.root)
        input_window.title(prompt_text)
        input_window.geometry("400x400")
        input_window.resizable(False, False)

        prompt_label = ctk.CTkLabel(input_window, text=prompt_text, font=("Arial", 15, "bold"))
        prompt_label.pack(pady=(40, 20))

        input_entry = ctk.CTkEntry(input_window, font=("Arial", 15, "bold"), width=300)
        input_entry.pack(pady=20)

        input_value = []

        def submit_input():
            try:
                input_value.append(float(input_entry.get()))
            except ValueError:
                input_value.append(None)
            input_window.destroy()

        submit_button = ctk.CTkButton(input_window, text="Submit", command=submit_input, font=("Arial", 15, "bold"),
                                      width=150)
        submit_button.pack(pady=20)

        input_window.wait_window()

        return input_value[0] if input_value else None

This method is very similar to the prompt_input method, but it specifically prompts for numeric input.

input_value = float(input_entry.get()) - Here, the input is converted to a float. If the user enters something that isn’t a valid number, a ValueError is caught, and input_value is set to None.

And that's all about it! You have successfully built an application with Stellar! That was easy, right?

Oh wait, we didn't run the application yet.

Running the application

if __name__ == "__main__":
    ctk.set_appearance_mode("dark")  # Use system theme
    ctk.set_default_color_theme("green")  # Default color theme without customization

    root = ctk.CTk()
    app = StellarWalletApp(root)
    root.mainloop()

The following image is a sample of how the methods and classes should be indented in the script.

Now it's ready to be executed. Did it go well? Please let me know if you are facing any bugs, have some errors, or if things don't work out.

Find the full script on GitHub

Testing...

It's time to make sure it works.

Create an account:

As far as my research, there's no way to check the validity of the account with no funds, so you'll have to be satisfied with the program creating a public and secret key. To fund an account, you can use Stellar Friendbot. All you have to do is run the following URL on a browser, with YOUR_PUBLIC_KEY replaced by your actual public key.

https://friendbot.stellar.org/?addr=YOUR_PUBLIC_KEY

Check Balance

If your Public key is correct and has been funded, the balance and asset type of the account will be displayed in our results_label. (View the demo video)

Send payment

This is where things may get tricky.

To send and retrieve the payment, you'd need 2 accounts. For these accounts to be identified by Stellar Network, they must have a balance exceeding 1 Lumen.

The easiest way to create 2 already funded accounts would be to use "GAIH's XLM Emporium" from Superluminal - ftl.ai. Other than creating accounts, it also keeps track of the accounts which helps a lot in testing these transactions.

However, if you're feeling too lazy to do all that, you can just copy/paste the following source and destination accounts.

-> Source Account

Public Key - 
GA5WU7PTF47VWOSSYBDMEVSLMENEFAGUY3LN6YJJCJ2LRIHQ2R2O5OUE

Secret Key - 
SCIY762XT7PP4AB2L35X7XTCTXZMMEQNVITE4WJWXH4RWIQWXLCCRYE7

-> Destination Account (for Payment)

Public Key - 
GDJ6VRIAZHGWN4ZTKRU3ADDXSMZUGIQQ54AGBBZOWMJ27VXAIEFB3GPH

Next Steps 🐾

Now that you have a functional stellar wallet application, the future possibilities are endless!

You can make this application look good with a GUI.
You can deploy this somewhere and make it available for the users.
Or better yet, you can put this project in your portfolio.

Whatever the next step is, you have already developed your experience and knowledge in working with Stellar.

Happy pythoneering!

Become a "Better" Programmer

Buzzpy 💡 — Mon, 05 Feb 2024 03:07:02 +0000

Hey there, Buzdies! As far as I learned from being in tech for around 3 years, becoming "better" in programming isn't all about mastering a certain programming language or several languages— it's all about how we think. No matter how vast your tech expertise is, to solve a problem, you have to follow "better" ways when working on programming challenges, projects or whatever. And that's what we cover in this blog post.

TL;DR?

1. Coming up with the solution

As a beginner, I tried to process the steps of solving the given problem at the same time I was reading it. And yes, it leads to a lot of consequences. Consequence Number 1 is you messing up the whole thing— you are not doing any of both tasks correctly, neither understanding the problem nor thinking about solving it. I'd be able to solve it eventually but in fact, it would take me a lot of time.

So how do you do this correctly? Let's take the "Anagram" problem into consideration.

Given two strings a and b consisting of a set of characters. The task is to check whether two given strings are an anagram of each other or not. An anagram of a string is another string that contains the same characters, only the order of characters can be different. For example, act and tac are an anagram of each other.

Step 1 is, Read it twice: don't think about inputs, data type conversions, iterations, conditional statements, how much caffeine it would take to solve it, or anything, just read it. When reading for the second time, you can highlight important points to consider. For example, you can highlight properties needed for a string to be an anagram.

And then comes step 2: Break it down!
_I love notebooks when it comes to this. Scribbling with a pencil is the best way to solve problems, small to big (choose a good pencil with that perfect sound). Write the first algorithm you get in your mind. It can vary from the correct one if you're just starting but when you improve your problem-solving skill, the first one is often the correct one (which means it WILL work).

When reading the above task, the first thing that came to my mind is as below.

Image by the author

Remember: Don't try to apply any syntax rule(S). You will get to it eventually. If you get the correct syntax (variables for example) even without thinking about it, that means you're really into coding.

And finally, step 3— writing the code.
If you're a beginner, I suggest writing the code in the notebook itself, as it helps a lot in modifications of the code. You can write down the code like this, and if you feel like there are more modifications to be done, write down that modified code, and if you still feel like you can refactor that code, Cool! Note down that piece too. Compare, notice, modify!

In the end, you'll have the perfect solution— the PERFECT one, and it didn't waste a second of your time, and it's a joy to code on paper. Us programmers need a break from the keyboard sometimes, you know.

2.Writing the code

Once you get the solution right, writing the code is easy-peasy-lemon-squeezy. But this is about being BETTER at programming, so let's cover a bit about this part too.

Tip #1: Meaningful (and beautiful) Names
We love 'em, don't we? A properly named code has a higher readability and we can easily understand what's going on by reading the code, no comments are needed. It will help your team a lot as well as you.

...and hopefully, you won't get yourself stuck in this situation.

Also, try to use CamelCase for variable and method names as it increases readability as well as the "beauty" of your code.

numberOne = 14 # Camel Case
number_one = 14 # NOT camel case,
                 # whatever it's called

Tip #2: Good Comments Make Good Moments
Every single programmer on the earth is tired of comments that explain "WHAT THIS IS". Your comment doesn't need to explain what you're doing; explain why you are doing it.

For example, if you comment like this, it's an obvious sign you are a jerk.

def anagram(word1, word2):
    word1.lower() # converting given input to lowercase
    word2.lower()

    word1_list = list(word1) # converting input to a list of chars
    word2_list = list(word2)

Even non-coders might be able to say what you've done in that piece of code. But the following example, of course, is from a good programmer,

def anagram(word1, word2):
    word1.lower() # so that this doesn't differentiate between lower and upper cases
    word2.lower()

    word1_list = list(word1)  # to split the letters— easy to sort and find len
    word2_list = list(word2)

Tip #3: Follow the KISS Principle
Keep it simple, stupid. It's not only about simplifying the code either. You must be able to take a step back and view whatever you just did from another person's view, who is totally clueless. I recommend you to check this article about KISSing your code.

Oh, I was just gonna miss it. You can find a solution for the anagram problem here. It's not the perfect one, but it does the job!

Testing your code

So, you've poured your soul into crafting that perfect solution, your fingers have danced across the keyboard to give life to your code, and now, it's time to put your creation to the ultimate test. Brace yourself as we unravel the secrets of testing, bringing your code to a level of excellence that even algorithms would tip their virtual hats to.

Tip #1: Comprehensive Test Cases - The Sherlock Approach
Picture yourself as the Sherlock Holmes of code testing. Investigate every nook and cranny of your program with a diverse set of test cases. Consider the usual suspects - the common use cases, the tricky edge cases, and the dark alley of potential errors. A comprehensive array of test cases ensures that your code stands tall and proud, ready to face any challenge.

Tip #2: Automated Testing - Your Code's Personal Butler
Why manually perform tasks that your loyal servant can handle? Enter automated testing, your code's personal butler. Tools like pytest for Python or JUnit for Java tirelessly execute your tests, providing rapid feedback on your code's functionality. Sit back, relax, and let automation be the backbone of your testing regimen.

Tip #3: Unit Testing and Integration Testing
Think of unit testing as the superhero examining each component's prowess in isolation. Meanwhile, integration testing steps in, evaluating the dynamic interplay between these components. A harmonious balance between the two ensures your code doesn't just play well with itself but shines in the grand orchestra of system functionality.

Tip #4: Boundary Value Analysis - Navigating the Edges
Navigate the edges of your code's universe with Boundary Value Analysis. Test those inputs that linger on the boundaries of acceptable ranges, uncovering vulnerabilities that might be hiding in plain sight. It's akin to exploring uncharted territories, where the true mettle of your code is put to the test.

Tip #5: Continuous Testing - The Ever-Vigilant Guardian
Imagine an ever-vigilant guardian standing by, ready to protect your code from regressions and unexpected pitfalls. Welcome to the realm of continuous testing. Tools like Jenkins or Travis CI tirelessly run tests whenever your code changes, providing real-time insights and ensuring your code's integrity remains unblemished.

Tip #6: Peer Reviews - The Code Conclave
Gather your fellow developers for a code conclave. Let peer reviews be the crucible where your code undergoes a baptism of scrutiny. Constructive feedback from your coding comrades not only fortifies your codebase but also hones your skills, creating a culture of collective improvement.

In the world of programming, testing isn't a mere step; it's an odyssey, an ongoing quest for perfection. Embrace these testing tips and best practices, infuse your code with resilience, and let your programming endeavors stand as a testament to the artistry of a true code artisan.

Summing Up

That's all in my mind right now. Hope you learned how to work like a "better" programmer on a project, challenge, hackathon, or whatever!

Side Note - I'm currently testing how ChatGPT can assist us in technical writing. Please be kind enough to share feedback about this article, as AI has written over 56% of this article (not to mention that part can be recognized easily). View ChatGPT Chat

The Programmer's Brain: How it works and how to make it work

Buzzpy 💡 — Wed, 24 Jan 2024 06:30:13 +0000

1. Reading Code Better 🔍

       - Quickly reading your code
       - The Power of Chunking
       - Learn Programming Syntax Quickly
       - How to Read Complex Code

2. Thinking about Code 💭

       - Reaching a deeper understanding of code
       - Getting better at solving programming problems
       - Misconceptions: Bugs in thinking

3. Writing better Code 📝

       - How to get better at naming things
       - Avoiding bad code and cognitive load: Two frameworks
       - Getting better at solving complex problems

4. Collaborating on Code 👥

       - The act of writing code
       - Designing and Improving Larger Systems
       - How to onboard new developers

Summary + Giveaway!

Hey there, buzdies! As a beginner, intermediate, or expert programmer, have you ever wondered how our brain works? Is it different from others or just the same?

Well, while I'm unable to answer that question exactly, Felienne Hermans' book The Programmer's Brain uncovers great insights about the programmer's brain; not just about the programmers but anyone who works with code.

TL;DR: The Programmer's Brain by Felienne Hermans focuses on understanding how our brain works when reading, writing and thinking code and how to do every task related with coding, in a better/quick way, followed by varioous exercises, insights and research outcomes.

This detailed review includes key points mentioned in the book, but to unlock your brain's full potential, I recommend you to read the book "The Programmer's Brain" by Manning Publications, which is offering a 45% Discount for all its publications exclusively for my readers (and yes, you're one of 'em) if you're using below code at the checkout.

💡 Enter this code at the checkout - buzzpy24

Also, I'm giving away 2 free e-books of "The Programmer's Brain", selected randomly from whoever fills out this Google form.

Back to the context— the book mainly covers 4 parts Reading Code, Thinking about Code, Writing Better Code, and collaborating on Code.

Let's see what each part covers.

1. On Reading Code Better 🔍

The book begins with an interesting part— how does our brain read code?

Reading code, ours or others is a core part of programming. According to the book, research indicates that almost 60% of programmers spend time understanding rather than writing code. Code reading is not taught or practiced often, and getting to know code is confusing and hard work. But before teaching how to read code in a better way, this book shows how the brain normally reads code.

It states that when we're reading code, our brain tries to process it while reading, but we're not able to clearly express how it processes the code or what it relies on. And then the book shows 3 types of confusion that may occur when reading a certain program, followed by a practical activity where a certain program is written in 3 different languages and you are to read and understand what happens.

Give yourself a few minutes to deeply inspect these programs. What type of knowledge do you rely on when reading them? How does that differ for the three programs? You might not have the words at this point to express what happens in your brain when you read these programs, but I would guess it will feel differently for each.

After this, we can clarify how we read the code, and why did we get confused. Accordingly, the 3 types of confusion are,

Confusion type 1: Lack of knowledge
Confusion type 2: Lack of information
Confusion type 3: Lack of processing power

Thereafter, the book describes cognitive processes related to programming— STM (Short-term memory), LTM (Long-term memory), and Working Memory in depth. By the end of Chapter 1, you'll be able to express what's happening in your brain while reading a certain program.

Quickly reading your code

The 2nd chapter of this part, "Speed reading for code" first analyzes why reading code quickly is hard, and how to overcome size limits in our memory— Chunnking our code and I love what this chapter covers.

As I mentioned earlier, when it comes to real life, code reading is more important than writing code itself. Thus, reading code clearly affects your programming expertise.(— well, I didn't think about that before). The first section of the chapter is also followed by an activity where you're given a Java program and asked to reproduce it after examining it for 3 minutes, from your memory.

As it sounds, it's not an easy task. The following illustration demonstrates what happened to your brain during the activity.

Source: The Programmer's Brain Book

Then the book uncovers why it's hard to read unfamiliar code, followed by an amazing explanation of the size limit of your short-term memory, and how it needs to collaborate with LTM to overcome its size limitations.

The Power of Chunking

This part is followed by the results of a research conducted by Adried De Groot ("Groot" is pronounced more likely as "Growth" rather than "Root" of "Boot", by the way) to find out why one person can become a great chess player while other players are bound to remain “medium” chess players for their entire lives.

In his first chess experiment, experts and average chess players were asked to remember a chess setup. Expert players were able to recall more pieces than average players.

Source: The Programmer's Brain Book

His conclusion was that the expert players outsmarted average players because expert chess players simply had an STM with a larger capacity than average players.

But his second experiment's outcome was surprising. This time, instead of showing the participants a real chess setup like in experiment 1, he showed them chessboards with randomly placed pieces—and not just a little bit random; the chess pieces were set up in entirely unrealistic configurations. And the outcome: both expert and average players performed equally badly.

That's when De Groot decided to find out how exactly the players remembered the chess setups. It turned out that in both experiments the average players mostly remembered the setups piece by piece. They would try to recall the setups by saying “A rook at A7, a pawn at B5, a king at C8," and so on.

Expert players, on the other hand, recalled the setup, and heavily relied on information stored in their LTM. For example, they might remember “a Sicilian opening, but one knight is two squares to the left.” Remembering the setup like that, of course, is only possible if you know what pieces are used in the Sicilian opening, which is stored in the LTM.

Just in case you're wondering what Sicilian Opening is.
Source: Quora

So what does this have to do with programmers? This means, if you have enough information in your LTM, your STM can easily retrieve relevant information from LTM overcoming its size limitations, ultimately helping you to read (and process) code faster than ever.

In the next chapter, the book will uncover how to store information in your LTM quickly and reliably. The rest of this chapter also includes some more interesting research and activities, but here's a summary.

When you lack enough knowledge in your LTM, you have to rely on low-level reading of code, like letters and keywords. When doing that, you will quickly run out of space in your STM.

When your LTM stores enough relevant information, you can remember abstract concepts like “a for-loop in Java” or “selection sort in Python” instead of the code at a lower level, occupying less space in your STM.

When you read code, it is first stored in the iconic memory. Only a bit of the code is subsequently sent to the STM.

Remembering code can be used as a tool for (self) diagnosis of your knowledge of coding. Because you can most easily remember what you already know, the parts of code that you remember can reveal the design patterns, programming constructs, and domain concepts you are most familiar with.

Code can contain characteristics that make it easier to process, such as design patterns, comments, and explicit beacons.

All the above content is deeply described in the book, I highly recommend giving it a read,

The Programmer's Brain - Manning Publications

Learn Programming Syntax Quickly

Is it necessary to memorize programming syntax? We have ChatGPT, right?

Many programmers believe that if you do not know a certain piece of syntax, you can just look it up on the internet and that therefore syntax knowledge is not all that important. There are two reasons why “just looking things up” might not be a great solution. The first reason was covered in the previous chapter: what you already know impacts to a large extent how efficiently you can read and understand code. The more concepts, data structures, and syntax you know, the more code you can easily chunk and thus remember and process.

Plus, we don't need to get mad at ChatGPT generating code that is opposite to the code that we asked for and we can code with pleasure knowing that we can exist without AI.

The second reason is that an interruption of your work can be more disruptive than you think. Just opening a browser to search for information might tempt you to check your email or read a bit of news, which may not be relevant to the task at hand. You might also lose yourself in reading detailed discussions on programming websites when you are searching for related information.

Now that it's clear that it's important to remember programming syntax, let's move on.

The book introduces flashcards to learn and remember programming syntax quickly. Flashcards are simply paper cards or Post-Its. One side has a prompt on it—the thing that you want to learn. The other side has the corresponding knowledge on it.

When you use your flashcards regularly, after a while you might start to feel that you know some of the cards well. When this happens, you might want to thin out your set of cards a bit. To keep track of how well you know certain concepts, you can keep a little tally on each card of your right and wrong answers.

Source: "The Programmer's Brain" Book

The rest of the chapter covers How not to forget things, Strengthening your memories, and so on. I wish I could elaborate, but since this is just a "review" of the book, I'm unable to do so.

Let's see what the last chapter of Part 1 has got,

How to Read Complex Code

Sometimes, you'll get to read complex code— complex enough that you can not process it inside your brain. In such cases, you'll have to write down the changing values in the program.

Source: The Programmer's Brain Book

To understand why you sometimes need to offload information, you need to understand the third cognitive process mentioned in the book— The Working Memory.

Working memory vs. STM

Felienne Hermans has compared the STM to the RAM of a computer and the LTM to the hard drive. Following that analogy, the working memory is like the brain’s processor.

The working memory represents the brain’s capacity to think, to form new ideas, and to solve problems.

Source: The Programmer's Brain Book

Like the STM, the working memory is only capable of processing two to six things at a time— this capacity is known as the cognitive load. When you are trying to solve a problem that involves too many elements that cannot be divided efficiently into chunks, your working memory will become “overloaded.”

The rest of Chapter 4 introduces methods to systematically address cognitive load with examples and also the memory aids to use when your working memory is overloaded.

(That's 1.6K words just for the first part of the book, not to mention all that was just a scratch of the book! )

2. On thinking about Code 💭

This part covers thinking about code: how to deeply understand programs and avoid bugs in thinking.

Reaching a deeper understanding of code

In this chapter, the book mentioned something I have never heard about— The roles of the variables framework.

According to professor Jorma Sajaniemi at the University of Eastern Finland, the reason variables are hard to understand is that most programmers do not have a good schema in their LTM to relate variables to. Sajaniemi argues that we tend to use chunks that either encompass too much, like “variable” or “integer,” or are too small, such as a specific variable name like number_of_customers. Instead, programmers need something in between, which motivated him to design the roles of variables framework. A variable’s role indicates what it does within the program.

Sajaniemi argues that with just 11 roles, you can describe almost all variables. Those variable roles are— Fixed Value, Stepper, Flag, Walker, Most recent holder, Most wanted holder, Gatherer, Container, Organizer, Temporary, and Follower.

Must say that ♪I love it that way♫.

Source: The Programmer's Brain Book

According to the book, studies have shown that this framework can help students to mentally process source code and that students who use the roles of variables framework outperform those who do not. One reason it’s so effective is that often a group of roles together characterizes a certain type of program.

For example, a program with a stepper and a most wanted holder value is a search program.

If you want to annotate code to get a better understanding, you can use a set of icons to represent the above 11 variable roles. Felienne Hermans has included his set of icons with examples in the book as well.

Rest of the chapter 5 also covers many useful topics along with interesting research, and practical activities. I'm literally in love with this book!

Getting better at solving programming problems

As the title suggests, this chapter covers getting better at solving problems as a programmer. It suggests the use of models to solve problems.

Models

As the author suggests, Models are simplified representations of reality, and the main goal of a model is to support you in thinking about a problem and ultimately solving it. Models can have various shapes and levels of formality. A rough calculation on the back of a beer mat is a model, but an entity relationship diagram of a software system is also a model.

Models can be a big help in solving problems because they help the LTM identify relevant memories.

Then it comes to Mental Models.

The definition of a mental model that I like best is this one: a mental model creates an abstraction in your working memory that you can use to reason about the problem at hand.

This topic is followed by how to use mental models efficiently when reading code— along with the fork-and-spoon experiment's results conducted by Johnson-Laird.

And then the book uncovers various insights about "Notional Machines". Notional machines are abstract versions of how a real computer functions that are used when explaining programming concepts and reasoning about programming.

If I'm going to explain it further with examples, it's gonna take at least another 700 words so— give it a read yourself!

Misconceptions: Bugs in thinking

I love bugs, as much as I love this chapter!

(I have literally written an article about debugging— check it out if you won't get distracted)

It's true, sometimes those itchy bugs are just missing commas and syntax errors. But the book suggests that more often, those bugs are due to the mistakes in our thinking.

You might not know that a file needs to be closed after use, or you might assume that the programming language closes the file for you automatically, and thus a bug blows up.

But before diving into Bugs in thinking, Felienne Hermans explains why learning a second programming language is easier than learning your first programming language, and how to benefit from your existing programming language.

Misconceptions

The book says that when you are sure your code will work, but it still fails, chances are that you are suffering from a misconception. For a belief to be a misconception, it should be faulty, be held consistently across different situations, and be held with confidence.

Felienne has mentioned a great example of a misconception in programming: New programmers sometimes assume that a variable, like, can only hold one value that cannot be changed. While that assumption might sound absurd to an experienced programmer, there are reasons why assuming that a variable can only hold one value is sensible— this assumption might be transferred from prior knowledge of mathematics, where variables indeed do not change within the scope of a mathematical proof or exercise.

While the rest of the chapter uncovers some common misconceptions about programming, and how to suppress them, here's a summary:

Misconceptions are not always addressed by simply realizing or being told you are wrong. For misconceptions to be fixed, you need a new mental model to replace the old, wrong model.
Even if you have learned a correct model, there is always the risk you will fall back on using the misconception.
Use tests and documentation within a codebase to help prevent misconceptions

And then let's jump into the part 3,

On writing better Code 📝

This part moves our attention to writing better code: how to write understandable code and avoid vague names and code smells.

How to get better at naming things

Fortunately, the above topic is widely discussed among developers and developers ARE getting better at naming things. Thus, I won't go further in this chapter.

The book discusses why naming matters with examples, and different perspectives on naming, and then comes an interesting part— Cognitive aspects of Naming. It's said that Formatting names support our STM, while clear names support our LTM. And also variable names can contain different types of information to help you understand them.

Source: The Programmer's Brain Book

The rest of the chapter discusses many more interesting things such as what types of names are easier to understand, snake case and camel case, the influence of names on bugs, and how to choose better names.

Avoiding bad code and cognitive load: Two frameworks

This chapter uncovers the connection between code smells and cognitive processes, especially cognitive load, and surveys the connection between bad names and cognitive load.

(Well, I accept that I didn't know what "code smells" is but turns out code smells are parts of code that are not structured ideally. Like, very long methods or overly complex switch statements, you know.)

This chapter includes an overview of Fowler’s smells (long method, lazy class, data class, etc) and the levels (method level, codebase level, and class level ) they pertain to with an in-depth explanation of the code smells' levels.

It also includes how to measure cognitive load, using the PaaS scale (not to be confused with the "Platform as a service" abbreviation) along with an exercise.

Phew, that's a lot of words but we still have 4 more chapters, so move on!

Oh by the way, have you seen what a baby penguin looks like?

Getting better at solving complex problems

This chapter uncovers about the "The State Space"— All steps that we could consider while solving a program are called the problem’s state space. When playing tic-tac-toe, all possible fields are the state space.

(It's kinda like the sample space which includes possible outcomes of a certain event- that's another thing anyway)

As an example in programming, when adding a button to a website, all possible JavaScript programs are the state space. It is up to the problem solver to make the right moves or add the right lines of code to reach the start goal.

Source: The Programmer's Brain Book

After introducing what's problem-solving, Hermans answers a question that has long-germinated in my mind— Is problem-solving a cognitive process on its own? He answers this question along with George Pólya's book. His book proposes a “system of thinking” to solve any problem involving three steps:

Understanding the problem
Devising a plan
Carrying out the plan

However, the book states that research has consistently shown that problem-solving is neither a generic skill nor a cognitive process, despite the popularity of generic approaches. There are 2 reasons why,

You use LTM to solve problems
It's easier for your brain to carry out familiar problems.

The rest of chapter 10 uncovers many insights A new type of cognitive load(Germane load,) implicit memory, and memories that play a role in problem-solving.

On Collaborating on Code 👥

While the previous parts focused on an individual developer, this part is dedicated to collaborating with other developers.

The act of writing code

In the first section of this chapter, this chapter focuses on five programming activities, what programming tasks you likely do in these activities, and what makes each activity hard.

Source: The Programmer's Brain Book

Each activity is explained in depth and then comes something interesting— Interrupted programmer.

Source: Pinterest

This is a very relatable experience for all of us, and of course, it affects our productivity. Van Solingen has found out that interruptions are common and take 15–20 minutes each. About 20% of a developer’s time is spent on interruptions.

According to the book, It takes about a quarter of an hour to start editing code after an interruption. When interrupted during an edit of a method, programmers could resume their work in less than a minute only 10% of the time.

But the best thing is, this chapter has got us covered. It includes how to better prepare for interruptions with three techniques and an important question has been answered— when to interrupt a programmer and also some thoughts on multitasking.

Designing and Improving Larger Systems

In this chapter, the focus shifts from individual lines of code to the broader aspects of organizing code for better understanding.

Felienne introduces C*ognitive Dimensions of Codebases (CDCB)*, a framework derived from Cognitive Dimensions of Notations (CDN). CDCB allows developers to assess the usability of large codebases and gain insights into how they can be understood and improved.

The chapter further discusses cognitive dimensions of code bases (CDCB) and uses it to examine a codebase to understand how it can be understood and improved. CDCB is especially useful for code written in libraries and frameworks, which other programmers often call rather than adapt. The chapter first discusses each of the dimensions in isolation and then dives into how the different dimensions interact with each other and how we can use them to improve existing codebases.

That's a long way around, thus let's save it to read for later and jump into the last chapter.

How to onboard new developers

Now that looks interesting.

As the title suggests, this chapter is about welcoming new developers or expert developers to an unfamiliar codebase. But first, the book discusses the difference between beginner developers and expert developers, starting with an overview of the four different neo-Piagetian levels for programming.

Source: The Programmer's Brain Book

After an in-depth explanation of the neo-Piagetian level, the author explains the difference between seeing concepts concretely and abstractly, along with some mindblowing insights.

And then comes the part I want every senior developer to read: Activities for a Better Onboarding Process, where he suggests 3 activities that are explained in depth. He suggests limiting tasks to one programming activity, supporting the memory of the onboardee, and reading the code together.

And now, finally, we have come to the end.

That's just a bit of the book!

I agree, this review contained a lot— actually, this is one of the longest articles I've ever written but yet, I did skip a lot of parts of the book. For example, I didn't mention Feitelson’s three-step model for better variable names, the fact that "If you can learn French, you can learn Python", and a lot more interesting facts and insights.

I appreciate you for reading this too-much-detailed review, and since you've read this so far, why not get the book and read it yourself?

The Programmer's Brain - Manning Publications
It's really worth the $40, besides, you can get a 45% discount by using the code buzzpy24 which can give you 18$ off this book which makes it: $22 only.

Oh by the way, I'm also giving away 2 free e-books of "The Programmer's Brain", selected randomly from whoever fills out this Google form.

Until the next article, happy coding!

If you have any suggestions/criticisms (I'm sure that this review is very lengthy and many contain many faults/mistakes), feel free to comment!

Branding for Developers : A Practical Guide

Buzzpy 💡 — Sun, 14 Jan 2024 07:19:34 +0000

Read the AI Version of this article

Hello, precious bug dealers! Huge kudos to you for diving into the world of building your brand. Believe me, not every software developer explores this path.

By the way, what is “Personal Branding”? Let me explain.

“Personal branding is the art of consistently presenting, online and offline, the essence of how you stand out from the crowd.”

In other words, you need to be consistent and work on specific things that are a part of you and how people see you. So it’s really about you－about yourself, who you are, and who you want to be.

Oh wait, let's be kinda honest, shan't we?

Practically and honestly, personal branding is about how you wish to be seen because, let's face it, whether or not you consciously care about others' opinions, it holds significance.

So yes, since you have taken the first step, we can take the BIG step of building your brand. But in case you’re still wondering why on the earth you need to build a brand as a developer, I summed it up.

1. It Opens BIG OPPORTUNITIES!

Same as everyone, you too might be applying for many and many jobs if you find a match but only some of them accept you.

As a developer personal branding matters when you are looking to change your job. You want your employers to hire you not only as a good developer but also as an innovative one. To make that possible, you need to cultivate a personal brand that can highlight your value to your potential employers.

For a real example, Victoria Lo, a developer with a strong brand, landed a job at Paypal, without sending a single application or a CV.

2. You can learn more and more!

While creating a personal brand, you meet many people from your niche. You interact with them, share your knowledge, learn from them, and discuss ideas and all this will give you a level of expertise that wouldn’t have been possible otherwise. It doesn't matter how you want to improve your career, personal branding is the key!

Yup, I think that’s enough. Now the important part is how to build your brand. Here's how.

Building Your Brand

Here are the steps you have to follow to build your strong brand.

1. Find your brand personality (name, brand color, etc.).

The most important task. If this fails, everything fails. But don't worry, I will guide you.

First, choose the brand colors. It’s totally up to you. But make sure it’s remarkable. If someone sees your brand color, they must remember who you are.

One thing you should remember is to choose living and unique colors. If you’re an individual, I highly recommend not using just black and white. Seeing the colors black and white everywhere feels like it's not alive. Use some colors like blue, pink, green— any color that looks alive, and fresh.

For example, Chris Bongers has chosen a combination of colors such as pink, blue, and yellow as his brand colors, and now no matter where you see those, the name "Daily Dev Tips" will come right into your mind.

And the most important thing— building your brand name. Sounds easy, right? But it’s not that easy; at least for me, it was not easy.

Your brand name doesn’t always need to be your real one. If your name is too long and hard to spell or pronounce, it might not be able to build a strong brand. This is where a lot of developers fail.

Taking my brand name as an example, it might seem meaningless but by the moment someone hears it, they can spell or pronounce it. Besides, it gives a basic idea I always wanted— kinda messy yet sometimes over-energetic(which leads to unexpected disasters...). In my point of view, it's just perfect!

I think now you have an idea of how what your brand name should be. But I’m sure it’s not easy to build a strange name. What about a name that has terms of your area of expertise, one of your characteristics, or even your pet’s name? For example, my name is built up with Buzz + Py. Buzz is used to feeling messy (one of my traits. To say, my code is not messy) as well as to remark the famous FizzBuzz program while Py is for Python.

What I did first was to write all the names/terms in my mind on Notepad and try to match them. Those words are still saved, and they look like this:

Once you’re done with all those, you must define yourself! Yes, personal branding is all about you.

What’s my name? (Brand Name)
What are the colors that define me? (Brand Colours)
What’s my Profession (Programmer, Developer, or whatever. Feel free to build up your own if you’re a freelancer!)
How should I sound? Professional or Friendly? (Brand Voice)
What's a phrase or a sentence that best describes me? (Brand Tagline)
What do I do mainly? (say coding)
In what areas do I have expertise?
What are the other things I do? (maybe your hobbies or other side hustle you make money)
What are my most unique personal traits?

Remember about the gift I mentioned before? I'm not sure whether it would be disappointing (hopefully not), but here it is— A brand info sheet! Just fill out the form, save it, and keep it yourself for future reference.

Download your information sheet from Google Drive - https://drive.google.com/file/d/1KIuZQLP_5uzOTOkcmQakuGgo66Tj-VRr

Let’s take an example. My answers to the above questions are,

Buzzpy.
Grey and Blue.
Python Developer.
Friendly, Conversational.
The Buzzy Pythoneer
Python Programming.
Data Analysis, Technical Writing.
Reading, Branding.
Buzzy (Chilling or messy, stands for both of them), Introverted.

And here it is, my personal brand. Nothing less, nothing more.

2. Start your Blog

What’s better than blogging to tell people who you are? Blog about anything you hold expertise in, whether it is a programming language or it is some kind of technology, and let people understand who you are. Many developers out there have some awesome technical blogs where they share their knowledge and write about their specialties.

If you need to start a free developer blog while getting inspired, Dev Community and Hashnode are the best options! Hashnodes gives you your blog even with a custom domain and saves you a lot of time building up your blog!

3. Participate in Communities:

Communities like Quora, StackOverflow, etc can be your best friends if you intend to create a brand online. Join these communities and try your best to solve the questions of users from your niche. It will not only help you interact with your kind of people but will also improve your problem-solving skills. Sites like Stack Overflow, and GitHub allow developers to work together on projects, which can open a wide opportunity to learn.

4. Reach out to Social Media

I’m an introvert, and I have a really difficult time when it comes to social media. That’s the only reason for me to participate on LinkedIn, as a professional because I care about my stable mind a lot. But I highly recommend you reach out to other social media, especially Twitter (must I say "X"? ). It helps you a lot in building and promoting your brand.

5. Build Your Principles

When it comes to branding, following your principles is important. You must never be a money-hungry person who will do or change anything for a rate. Whether it loses you 1000 dollars, do not cross your line.

For example, if someone asks you to do a review on one of their bad products to increase users and offers you a lot of money to promote it as an excellent product, just say “No, Thanks.” Not like the $1500 they offer, if you get attention for being a fake reviewer and people stop following/ reading your content, it may lose you more than a thousand dollars and your whole brand and effort.

Next Steps 👣

That’s a lot of words! First, thanks for reading until the end. I hope you learned a lot of things and will get started on branding yourself as a developer as soon as possible. Yes, you might be late but late is a lot better than never! Try building your blog if possible, because it’s the best way to get recognition. If you’re not interested in writing, build a portfolio or stand out on Social media!

Until next chillin' Friday, Happy Branding!

Download your information sheet from Google Drive - https://drive.google.com/file/d/1KIuZQLP_5uzOTOkcmQakuGgo66Tj-VRr

Did you know the blog "ByteClash : AI vs. Buzzpy"? Every article or tutorial there is like a double take, coming at you from two different angles— the smart side of AI and the friendly touch of a human.

Visit ByteClash : AI vs. Buzzpy
Read the AI Version of this article

Why you should ♥️ Debugging?

Buzzpy 💡 — Fri, 12 Jan 2024 04:49:09 +0000

Hello again, buzzdies! Hope you had such a great week 😊

Alright, let’s get into the thing. By the time you read the title of the article, I’m sure you were like….

“What the hell are you talking about!?”

I understand because programmers or developers usually hate debugging, but what if we look at the other side of debugging? We always think that the time spent on debugging is such a waste of time, but that’s not true. Time spent on debugging is Golden!

Yup, that’s a weird sentence. But by the end of this article, I think you too will agree with me.

Debugging is the best way to learn

Every programmer hates debugging, especially beginners. So did I at the beginning. I spent months learning to code, and when I started to build an application, I had to spend days just debugging the code. That’s not fair.

But later, I tried to understand the other side of it; if I’m finished with learning to code, why do I have bugs everywhere? That simply means I have a lot more to learn. Does that mean I have to go through another ton of courses?

That’s where I started to thank those buggy bugs in my code. When I have a lot of bugs to debug when writing code, I don’t have to spend years learning everything through courses or whatever, because when I find a solution to one bug, I have learned a bunch of important things.

There are many things I learned through debugging— Working with Threads and Async Functions, Different ways to import external scripts, running EXEs through different methods, and a lot more, which were never included in the courses I went through.

Debugging develops Soft Skills

The second I face a bug, the first thing that comes to my mind is ‘Why is it always me!’. And when I spend hours trying to fix it and nothing works, I want to shut down this stupid thing and give up the whole project!

But when the time flies, fixing bugs for hours by focusing becomes a usual thing and we don’t feel the feeling we had as a beginner. In simple words, we can code like a monk. That means we have improved our patience and focusing skills, isn’t it?

Not only that, debugging helps to improve our communication skills as well. The best example is asking questions in StackOverflow. And since almost all of us have experience with that, I’m not gonna talk about it!

The main reason for improving our patience, communication, and focusing skills is Debugging. How can we hate it?

Tips for perfect debugging

Just in case you’re stuck with a lot of bugs and everything is messed up, these tips might be useful for you.

Ask Questions

Before starting to fix bugs, you need to ask questions about your code. A rubber duck or a stuffed animal might be really useful. (But be sure not to ask those from a non-programmer)

What do you need the program to do?
What does it do?
What are the issues you’ve found?
Have you encountered these types of problems before?
If yes, What did you do to fix them?
Where and why do you think the bugs occurred?

I personally use this too often, and it gives me a good result in return.

Focus on Error Messages as well

![Buzzpy(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9zqpzfagpn966zeqgelv.png)

Error messages aren’t just annoying messages — they actually tell you exactly what the problem is with your code. So the next time an error message pops up, make sure to read it as it can give you at least a small hint about what’s going on. If you’re not sure what the error message means, try searching for it online. Chances are someone else has encountered the same problem in the past and could know how to fix it.

Log Everything

This might seem like a boring thing to do, but it can save you a lot of time. Documenting every issue you encounter, as well as the steps you take to address them helps you to ensure that your program is running correctly. Once you’ve documented the error, you can start mapping out potential scenarios and solutions.

This will also allow you to navigate different potential solutions without repeating them.

Ask for help

In a lot of instances, the bug you found is encountered by at least one more person on the internet. It’s a good practice to reach out to a community that is specific to the framework/technology/tool you are using.

For a lot of programmers, asking for help from the community is the first option. But I don’t agree with it because, in that manner, we get less opportunity to learn something on our own, even though the error gets fixed.

If nothing works, take a nap

Believe it or not, this is one of the most worked solutions for me. There’s a psychological aspect to this as well. When you have debugged for hours and your head is messed up, a small nap, a walk or just a 30-minute break can refresh your brain. Who knows, maybe you have missed just parentheses or a semi-colon somewhere?

Conclusion

Debugging, hated by most developers has some beautiful sides as well. Understanding and looking at what is positive, can change everything, and even make you fall in love with debugging!

Enjoyed the article? Make sure to subscribe to "The Buzzletter" so you will never miss any of my content + any gifts I offer! 🐳

(https://subscribepage.io/the-buzzletter)

Analyzing Amazon Data With Pandas - Beginner's Guide

Buzzpy 💡 — Thu, 21 Dec 2023 18:16:22 +0000

Hello, buzdies! 👋

Pandas is one of the most helpful Python libraries used by millions of data scientists and analysts today. Along with other libraries like Matpotlib, Numpy, and Plotly, Pandas has been the backbone of numerous large-scale projects.

If we take a simple example, think that you have a CSV file. With pandas, we can make it a data frame— or we can say a "table" with some data. And then, with just a simple keyword, you can find and analyze the data of each column and row— The mean, average, max, min, and everything!

In this tutorial also, we’re going to learn the fundamentals of Pandas which will give you a perfect start for your data analysis journey. And one more advantage, you’re going to analyze your Amazon data as well!

Oh, by the way, code samples in this tutorial can be found in the GitHub repository as well.

https://github.com/Buzzpy/Amazon-Data-Analysis

Getting Started

Install Pandas(pip install pandas) and import it (import pandas as pd)
Download Amazon Data Report

Sign in to your Amazon Account.
Go to Your Account > Account.
In the Order and Shopping Preferences section, select “Download order reports”.

In case you’re not an active Amazon user, here’s a small CSV file containing some of my personal data (some data aren't present)

But wait, what is Pandas?

Pandas is a beloved library used by both Data scientists and analysts. So if you’re a data geek, Pandas is an essential skill you’ll need.

The reason Pandas is among the top data science libraries is that it has many built-in functions that help to analyze and clean data in seconds. Below are the widely used Pandas functions.

pd.read_csv(): To read CSV files.
pd. DataFrame(): Convert Python objects (such as Lists) to a DataFrame. No need to use it when using CSV files.
df.head(): df stands for DataFrame and head() can be used to show the first 5 rows while tail() is used to show last 5 rows.
df.shape(): To find no: of rows and columns.
df. isna(): Find null values.
df.fillna(): Fill empty cells with something, say 0.
df.astype(): Convert data types.
df.sum(): Get the sum of values in a column.
df.columns(): Get the full list of columns.
df.drop_dulicates(): Drop all the duplicates.

Reading Data 🔎

Now you can guess the code we can use to read our CSV file with Pandas. Yup, we will use the pd.read_csv() function. But before that, make sure you’ve imported Pandas library as below.

import pandas as pd

df = pd.read_csv('Amazon Dataset.csv')
pd.set_option('display.max_columns', None) # display all the columns
print(df)

The output would print all the data in your CSV file.

Data Cleaning 🧹

In any project related to Data, cleaning data is an important step.

In the previous output, you’ve seen that some columns have values called “NaN”— which means no data is present. Therefore, let’s deal with Null values first. Don’t worry, it has become very simple with Pandas built-in function df.fillna()

If you compare the output of this code with the previous one. You will notice that those ‘NaN’ values have been replaced with 0.0.

The next thing we need to do is delete duplicates. Even though this CSV file might not contain any duplicates, it’s always a good practice.

df.drop_duplicates()
pd.set_option('display.max_columns', 36) # display all the columns
df = df.fillna(0)
print(df)

There’s one more important job. In the output, you saw that some columns(Item Total) contain Price in USD, with a dollar sign ($) in front of them. This makes its data type a String, which is a barrier to calculations with it.

So we have to use the following code to remove the dollar sign and convert it to an Integer.

df.drop_duplicates()
pd.set_option('display.max_columns', 36) # display all the columns
df = df.fillna(0)
df["Item Total"] = df["Item Total"].str.replace('$','').astype(float)
print(df)

Output:

That’s Awesome! We can move to the next part now.

Find the total spending

The most interesting part is here! Now let’s see how much you’ve spent on Amazon. Since we have converted the Item Total column to floats, it’s easy to take the sum of the column using sum() function.

df = df.fillna(0)
df["Item Total"] = df["Item Total"].str.replace('$','').astype(float)

print(df["Item Total"].sum())

For this dataset, my result was:

1968.2999999999997

That means I’ve spent almost $2000 on Amazon. Gosh, that’s a lot for me. How much was yours?

Highest, Minimum, Average

Now let’s find out what’s my highest spending. The only thing you have to do is update the previous code using max() function instead of sum().

print(df["Item Total"].max())

And my result was:

999.57

Well, I must find what I have which is worth a thousand dollars!

To calm down after finding your biggest purchase, let’s find what is our lowest purchase price. In this time too, you have just to replace max() with min().

print(df["Item Total"].min())

And the output was:

1.01

Which means my least spending on Amazon is $1.01.

The final task of this tutorial is to find your average spending on Amazon. We will be using mean() function, replacing min() in the previous code.

print(df["Item Total"].mean())

Output:

151.4076923076923

Ignoring decimals, my average spending was $151 but to make sure, I'm going to use the median() function as well.

print(df["Item Total"].median()

Output:

96.02

That's quite different, right?

The difference between the mean and median in our dataset indicates that the distribution of "Item Total" values is skewed, probably due to a few high-spending outliers. The mean is sensitive to extreme values, and their influence pulls it higher than the median, which is less affected by outliers. This means that a small number of significant purchases are impacting the overall average, causing the mean to be higher than the median.

If we want a more clear representation of our average spending habits, the best idea is to create a visual representation such as a histogram. But as for these tutorials, we'll continue like this— our average spend is between $96 - $151.

Conclusion

In this tutorial, we learned much about Pandas— functions, different terms, etc. The key takeaway is that Pandas is a powerful and easy-to-use data analysis library that helps developers make their lives a lot easier when working with data.

https://github.com/Buzzpy/Amazon-Data-Analysis

Happy Coding!
————————————————————————————

Enjoyed the article? Make sure to subscribe to "The Buzzletter" so you will never miss any of my content + any gifts I offer! 🐳

View December's Buzzletter

How Do I Stay Happy as a Developer (And How do you do it? )

Buzzpy 💡 — Sun, 10 Dec 2023 15:32:19 +0000

Hello, buzzdies! Among thousands of productivity tools, have you ever figured out the best one ever? I bet you haven’t but don’t worry I have, and it's...

Happiness!

Yes, you've read it right. Nothing is a better productivity tool than happiness, especially for programmers and developers. But the problem arises, how do you stay happy with those devil bugs and thousand lines of code? Modern problems require modern solutions! 😉

And don't forget to share what you do to stay motivated or happy as a developer in the comments. Let's #discuss~

1. Working on a Great Project

This one can be quite obvious but programmers love great projects. In fact, if they find that the project is not that appealing, they won’t take it, unless there are no more free projects to participate in. Yes, we’re all the same.

If you find a project that you’re capable of but not interested in, I highly recommend you just ignore it. I know, you think that it's impractical when this project pays you a higher amount. But trust me, it may harm your whole career. Since you’re not that happy with the project, you won’t be able to deliver it to the best quality, and the client may be unhappy and unimpressed. Once he gives a bad review, everything you have done before is gone.

Imagine you work with something you absolutely adore, you love the area, you love your team and a set of technologies is amazing. Over time you know almost every aspect of your project, and you started to call it your baby. What’s better than it huh? The more you’re happy with the project, the more productive you are!

2. Building strong bonds with your team.

Software development is much better as a team sport. One alone just cannot do much, plus it can get boring. I indeed work solo currently but that’s all because I didn’t find a better team that matches me. But I wish I had at least one tech mate that really fits me.

Therefore, try to be as comfortable as you can with the team you're working on. Any social skill you can apply here will be good. Here are some tips that I wish my former teammates had and will be great to have in you too!

- Learn to take/give feedback:

Nothing can be more annoying than someone putting down your work. Never try to do such things and give constructive feedback. I have been an avid reader of Ajahn Brahm's Dhamma Talks and I found a great technique that can be used to give better feedback called the "Sandwich Technique". That way, you first tell them something good like "I really like the way you code, it's simple and easy to figure out". And then the bad thing you want to tell just like "But those comments need to be somewhat clearer." And again, something good such as "By the way, I love the naming of your variables and functions. Unlike me, they are very relatable". And Ta-da! You have made sandwich feedback.

- Practice team building activities:

It's really a pleasure to see many companies have done great in this. It can be as little as a Tea party on Fridays or as big as traveling abroad with the whole team!

- Thank someone every day:

This is a positive thinking technique that could apply to anything in your life. Send a message, email, or whatever to a colleague thanking him/her, even for very small things, such as giving a little review for a part of your code or something like that.

3. Saying “NO”

When you are doing really great work on your project, there will be a number of people who will come and ask you to join their team, startup, or whatever.

When you have the power to say "No", it feels awesome, especially if you find out later that that project wasn’t successful after all. You are feeling happy just because you saved lots of headaches and sleepless nights.

And yep, I have experienced that~

4. Manage Your Time as well as Priorities

Life goes (it flies, actually) fast nowadays, so fast that we go faster with it. And we end up in a routine where we try to do too many things that we can manage to do. That makes us over-demanding ourselves, leading to frustration and anxiety because of not completing the tasks, or doing them under much pressure for quite some time.

You want to prepare a talk, attend a meetup, keep your Open Source work, write on your blog, stay healthy practicing sports, hang out with friends, spend time with your family, run some side-project... and you work full time as well. Be careful, being too ambitious can turn against you.

Wondering what I do about it? Here you go!

Slow down and push the break: Minimize your task queue. Keep in mind it is better to do 2 things well than do 4 tasks badly and quickly.

Enjoy what you do: When you slow down, you have more time to pay attention to what you're doing, making it more enjoyable. That's what mindfulness stands for.

Use a time management technique: I love to use Pomodoro. The point is to enforce breaks to move and distract yourself to don't spend hours on a task continuously.

Oh by the way, did you know that I use my own Pomodoro application? I do! See how to make your with Python -
Make your own Pomodoro Application with Python

Conclusion

Phew, that’s a lot of words! Here we talked about a lot, including the importance of working as a team, the sandwich technique, managing your time, etc. Hope you enjoyed it!

Ugh, I was gonna miss it again. Here are some methods to keep your motivation at the full level, as happiness may depend on it as well!

Go Open Source: Now is easier than ever since an open-source guide has been created by GitHub itself and lots of experienced OSS devs.

Go to Meetups and Conferences: You'll meet lots of people physically, which opens a lot of doors and keeps you connected to more communities and their ecosystems. If you're brave enough to speak in one, you'll get a great feeling afterward, so go and try and see what it feels like!

Build side projects: It can be anything, such as building dummy apps, organizing events, sharing knowledge, creating libraries, etc. Some things I did is create this blog, contribute to some open-source projects, build the Buzz App, and read Dhamma talks of the Buddhist monk, Ajahn Brahm.

By the way, what do you do to stay happy as a developer? Let us #discuss in the comments!

Happy Coding!
————————————————————————————

Enjoyed the article? Make sure to subscribe to "The Buzzletter" so you will never miss any of my content + any gifts I offer! 🐳

View December's Buzzletter

Make your own Pomodoro Application with Python

Buzzpy 💡 — Fri, 08 Dec 2023 15:07:11 +0000

Hello buzzdies! I bet, most of you have heard enough about Pomodoro Technique, a time management method. In case you haven’t, lemme explain.

The Pomodoro technique is invented by Francesco Cirillo, around the 1980s. It encourages people to work with the time they have—rather than against it. Using this method, you break your workday into 25-minute chunks separated by five-minute breaks. These intervals are referred to as “Pomodoro”. The diagram below explains it further.

Source: https://sketchplanations.com/

This technique is for everyone, including programmers and developers as well. But working according to Pomodoro using a regular clock or alarms is very disturbing so it’s always better to have some software. And it’s much better if we can develop the software ourselves!

Yup, you got the point. This tutorial is on how to make a Pomodoro Application using Python, with User Interface. Move on 😉

In case you're in a hurry, the source code can be found in this GitHub repository. Open for PRs!

Visit Github Repo

Getting Started

First, we should import the libraries— math for calculations and tkinter for GUI. Since these are pre-installed, we can import them directly.


From tkinter import *
Import math

Basic UI

Interesting part first, let’s build the user interface.

Defining Global Constants

When working GUI, it’s a good practice to define global constants for properties like Color, Font types and sizes and etc. The following code does the job.

PINK = "#f81365"
RED = "#e7305b"
GREEN = "#9bdeac"
GRAY = "#EFEFEF"
FONT_NAME = "Barlow Condensed"

Setting Up

We’re going to use an ordinary Tkinter window, size 100 x 50. And the constant variables we declared in the previous part are used here.

window = Tk()
window.title("Pomodoro")
window.config(padx=100, pady=50, bg=GRAY)
title_label = Label(text="Timer", fg=PINK, bg=GRAY, font=("Barlow Condensed", 50))
title_label.grid(column=1, row=0)
canvas = Canvas(width=200, height=224, bg=GRAY, highlightthickness=0)
# highlightthicknes is used for making the highlight disappear
tomato_img = PhotoImage(file="tomato.png")# use your path
canvas.create_image(100, 100, image=tomato_img)
timer_text = canvas.create_text(100, 110, text="00:00", fill="black", font=("Barlow Condensed", 35, "bold"))
canvas.grid(column=1, row=1)
# count_down(5)
# x and y values are half of the width and the height
start_button = Button(text="Start", highlightthickness=0, command=start_timer, bg=PINK, font=("Barlow Condensed", 10))
start_button.grid(column=0, row=2)
reset_button = Button(text="Reset", highlightthickness=0, command = reset_timer, bg=PINK, font=(FONT_NAME, 10))
reset_button.grid(column=2, row=2)

check_marks = Label(text="✓", fg=GREEN, bg=GRAY)
check_marks.grid(column=1, row=3)


window.mainloop()

You may have seen that we used an Image of a Tomato in the above code. The image can be downloaded from the GitHub repository

Don’t hurry to test this code as it’s not ready yet! There are some functions and variables which aren’t been declared yet. So it is time to move to the next part,

Declaring Functions

First, we will finish the logical part. Here, we need three major functions. reset_timer start_timer countdown

Let’s start with the Reset function. But before that, we need to declare some more values as global constants, like below:

WORK_MIN = 25
SHORT_BREAK_MIN = 5
LONG_BREAK_MIN = 20
reps = 0
timer = None

Note: the value reps is used for governing the timing section of work and breaks and counting them.

Done!

`reset_timer`

In this function, we need to do to following things: Reset the timer text to 00:00 Cancel the timer Reset reps to 0 Delete the checkmark(used for counting no: of working time sections) We use the following code to do all of these.

def reset_timer():
   window.after_cancel(timer)
   canvas.itemconfig(timer_text, text="00:00")
   title_label.config(text="Timer")
   check_marks.config(text="")
   global reps
   reps = 0

Awesome! Now let’s move to the next part.

`start_timer`

Compared to the Reset function, the Start function is somewhat lengthy as it does some more tasks, such as below:

Add +1 to reps the variable Defining Long breaks and Short breaks.
Converting minutes to seconds

The following code can do all the above:

def start_timer():
   global reps
   reps += 1
   work_sec = WORK_MIN * 60
   short_break_sec = SHORT_BREAK_MIN * 60
   long_break_sec = LONG_BREAK_MIN * 60

   if reps % 8 == 0:     # If it's the 8th rep
       count_down(long_break_sec)
       title_label.config(text="Break", fg=RED)

   elif reps % 2 == 0:     # If it's the 2nd/4th/6th rep
       count_down(short_break_sec)
       title_label.config(text="Break", fg=PINK)

   else:
       count_down(work_sec)
       title_label.config(text="Work", fg=PINK)

Awesome! But we’re not ready yet, we have to write another function for counting down.

`count_down`

In this function, we need to do the following tasks:

Count down and change the text accordingly.
Put check marks for each work session.

Here’s the code we can use for these purposes.

def count_down(count):
   count_min = math.floor(count / 60)
   count_sec = count % 60

   if count_sec < 10:
       count_sec = f"0{count_sec}"
   canvas.itemconfig(timer_text, text=f"{count_min}:{count_sec}")
   if count > 0:
       global timer
       timer = window.after(1000, count_down, count - 1)
   else:
       start_timer()
       marks = ""
       work_sessions = math.floor(reps/2)
       for _ in range(work_sessions):
           marks += "✓"
       check_marks.config(text=marks)

Awesome! Believe it or not, we’re done with our Pomodoro Application. Here are some screenshots how what it looks like:

Default Window

Running...

On break...

Summary

In this short tutorial, we created an awesome-looking and simple Pomodoro application that can boost your productivity at work. The source code can be found in below GitHub repository,

View Repository
Don’t forget to fork, star, and contribute! Also if you have any questions or feedback, drop them in the comments.

Happy Coding!

Enjoyed the article? Make sure to subscribe to "The Buzzletter" so you will never miss any of my content + any gifts I offer! 🐳

Developer's Guide to "KISS" code

Buzzpy 💡 — Fri, 18 Nov 2022 13:55:24 +0000

Hello buzdies! When talking about the principles of programming, the KISS principle is remarkable. Standing for "Keep it simple, stupid", it is the most accessible principle to apply in real-life situations.

What does it actually mean?

Source: Unthinkable

The meaning of KISS is as simple as it sounds: Keep it simple, stupid. It's not only about simplifying the code. You must be able to take a step back and view whatever you just did from another person's view, who is totally clueless.

If you have built applications before, you might have already engaged in this problem by writing code and reviewing it months later. Many lines are unreadable crap because you couldn't take a step back and simplify the concepts.

I myself have experienced this thing when I'm trying to do some updates on programs I made a long time ago. More often, I end up being confused about the code so the little things take a lot of time than it really does because my code wasn't simple at all.

Why use KISS?

You should probably ask why not use KISS, which is easier for me to answer.

There are many reasons to use KISS. KISS principle in software development allows developers to tackle the most significant difficulty of software development— implementing changes to the code written by either you or another person. I think this reason is super enough to write KISS code when thinking about my experience itself.

There're a few other scenarios that make us think again about writing simple and stupid code:

You can solve more problems, faster by just looking at them.
You will be able to build larger systems that are easier to maintain
You're code base will be more flexible, and easier to extend, modify or refactor when new requirements arrive
You will be able to achieve more than you ever imagined, with some beginner-like simple code rather than large complex lines of code.
You will be able to work in large development groups and large projects since all the code is stupid simple

KISSing your code

Remember what I said first, the KISS principle is the easiest principle to apply in real life. Everything you need to do is, think like an experienced beginner.

Who is an experienced beginner? Lemme explain.

Let's think about an experienced beginner in Python. What does he know about Python? Basic programming stuff like data types, loops, conditions, and how to work with a few libraries. But remember, he is experienced— he knows that he will need to modify and update every piece of code he's writing.

When he is asked to create a calculator, he just uses a few conditions, inputs, functions, and a little math. It might be long, but it's readable for anyone even a non-programmer. According to me, this is the best implementation of the KISS code. It's so stupid and simple.

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
—Bill Gates

Here’re practical tips to apply KISS in programming.

Avoid Global Functions or Elements

The Global States or Global Variables or simply Globals, refer to states or variables whose scope extends to the entire application. Moreover, their state can change at run-time which means, they are mutable.

Although Globals appear to be an easy way to share states between parts of the application without having to pass them through functions, they are detrimental to the implementation of KISS principles.

Globals give rise to significant problems such as Global name collisions, low testability, and concurrency issues. Furthermore, Globals add to the overall complexity of the code. They often act as hidden elements whose change of state is undeterminable.

Avoid the Lasagna Architecture

The Lasagna Architecture is the outcome of a very strict layering approach wherein each layer only knows about the layer immediately below itself. Rather than actualizing the intended ‘perfect’ system, this approach often leads to an unnecessarily complex one.

Such a system is immensely complex to read, and making any changes to it is difficult. For even the slightest chance, the developer has to check most sections of the code, determine if the change in one layer would affect another, visualize the functioning of multiple layers, face unidentifiable errors in verification, and so on.

Avoid Abstractions and Dependencies

Abstraction is a process that envelopes a complex code block in a layer of simplicity. However, despite assigning a simple name to call the function, this method makes the overall process inherently more complex.

The function might have numerous interconnected parts, dependencies, and implementations of which the developer might be unaware at the time of calling. In fact, when abstractions aren’t dealt with properly, they ultimately lead to a lasagna architecture, resulting in related issues and undesirable complexities.

Moreover, abstractions heighten the risks of improper or unnecessary coupling, which is a major deterrent to simplicity. The same applies to dependencies. Although dependencies are inevitable at times, it’s imperative to avoid them whenever possible.

Avoid Dead Code

A habit among developers is to include lines of code that have no present purpose but are intended to be useful in the future. These are dead codes. By making systems unnecessarily complicated, they do more harm to the system than good.

Unless a line of code has any immediate purpose, it’s always better not to use it.

Conclusion

The meaning of KISS is as simple as it sounds: Keep it simple, stupid. KISS has now become my favorite coding principle because it requires nothing but thinking like a beginner.

Enjoyed the article? Make sure to subscribe to "The Buzzletter" so you will never miss any of my content + any gifts I offer! 🐳

References

http://principles-wiki.net/principles:keep_it_simple_stupid

DEV Community: Buzzpy 💡

Glitch v1: An LLM with a personality, anxiety and a bit of attitude

The “Thinking“

Is this a “clone“, really?

The behind-the-scenes

What’s uncomfortable about it

What V2 Might Look Like

Wrapping up

Introducing Dev Encyclopedia: A "Wikipedia", but for developers

What is Dev Encyclopedia?

But why use Dev Encyclopedia?

Contribute!

How to Contribute:

FAQs

1. Techstack and tools?

2. How long did it take?

3. Did you build it alone?

Building a Stellar Wallet App with Python : The Backstory

The Tutorial

Stellar + Python: The Ultimate Duo for a Payment App (Absolute Beginner's Guide)

What I Created

Journey

Next Steps

Special Thanks:

Stellar + Python: The Ultimate Duo for a Payment App (Absolute Beginner's Guide)

A look at the app

But wait, what's Stellar?

Prerequisites for the tutorial

Building the Stellar Wallet

1. Setting Up the Gear

2. Creating the main class

3. Configuring a Layout

4. The create_widgets() method

Application Title Label

Public Key Label and Entry box

Secret Key Label and Entry box

5. Creating the buttons

I. Create Account Button

II. Check Balance Button

III. Send Payment Button

Result label

6. create_account Method

Keypair Creation___

Account Existence___

7. check_balance Method

8. send_payment Method

9. Messages in Pop-up windows

User Input Prompts

User Input Prompts - Numerical Only

Running the application

Testing...

Create an account:

Check Balance

Send payment

Next Steps 🐾

Become a "Better" Programmer

1. Coming up with the solution

2.Writing the code

Testing your code

Summing Up

The Programmer's Brain: How it works and how to make it work

Table of Contents

1. On Reading Code Better 🔍

Quickly reading your code

The Power of Chunking

Learn Programming Syntax Quickly

How to Read Complex Code

2. On thinking about Code 💭

Reaching a deeper understanding of code

Getting better at solving programming problems

Misconceptions: Bugs in thinking

On writing better Code 📝

How to get better at naming things

Avoiding bad code and cognitive load: Two frameworks

Getting better at solving complex problems

On Collaborating on Code 👥

The act of writing code

Designing and Improving Larger Systems

How to onboard new developers

That's just a bit of the book!

4. The `create_widgets()` method

6. `create_account` Method

7. `check_balance` Method

8. `send_payment` Method

`reset_timer`

`start_timer`

`count_down`