Blog posts from feed-en-tech (#feed-en-tech)
Our commitment towards responsible digital storytelling.
Re: Why I quit being a tech "influencer"
Hi, and congrats for jumping out from the tech influencer bandwagon! As a form of motivation, you might not know that GitHub were actually co-founded by two people who still exist today without a personal blog website, and another two having personal blog sites that are nothing but plain old boring blue links, like Daniel Stenberg, the creator of cURL, and Pieter Levels, in case you know about him. Those influencers, as I personally called them Recycled Developers, often shared things which are not always technically accurate, especially in the long term. Even in DEV, a blog post named 17 Compelling Reasons To Start Ditching TypeScript Now was suddenly inspired someone else to write 18 Reasons to Use TypeScript SINCE YESTERDAY. It is as if that one technology, language, or framework will always be good enough and they shall defend their opinions at all costs. But the truth is, neither JS or TS are better to learn and use, and a better developer should be able to weight and choose the right parts for their project stack. And in fact, many of the tech jobs require from you, unless if you're into DevRel (Developer Relations), documentation, or writing tutorials like in MDN and Kodeco (formerly RyanWenderlich.com), is to build and maintain products through well-designed code, not well-designed content. Now I'm interested to read your ebook before it's gone, but that link redirects to http://localhost:3000/products/level-up-your-career-today-developer-edition/ for some reason. It might be interesting to compare it with my perspective as a developer who have done "classic" web development since 2014, Node.js since 2016, C in 2019, Java and PHP/Laravel in 2020, then Python, Swift, React (including Next and Remix), Go, Vala, and beyond over the last few years. But one thing for sure, everyone can start their dev career without forcing them to use HTML/CSS/JS, or Python, or Swift, or back to the good-old C. Concepts are more important to learn, and let those syntaxes and functions follow. (>_ ) 💕
What is the "shell" of Bearers of the Shells?
Sure, we found out that may people don't understand the shell thing we mean for the term "Bearers of the Shells". We're not selling seashells and don't own some shares on the Royal Dutch Shell, anyway. The shell, as in BOTS here is the computer shell, and we found it difficult to translate its meaning into non-English languages. Most languages just transliterate the word, anyway, because at the world of computing, the shell is a metaphor to a kind of the computer program that allows you to interact with other computer programs. Today, you can say that computer shells are quite similar to "skins" in Android (Samsung's One UI, MIUI, Google Pixel, etc.) or "desktop environments" in Linux and BSD operating systems. However, it's not always true. So, to understand what is the true meaning of the computer shell and the shell of BOTS, let's look at this research article (PDF) from 1965 written by the authors who first coined the word "shell". Shell, as the computer program. We may envision a common procedure called automatically by the supervisor whenever a user types in some message at his console, at a time when he has no other process in active execution under console control (presently called command level). This procedure acts as an interface between console messages and subroutine. The purpose of such a procedure is to create a medium of exchange into which one could activate any procedure, as if it were called from the inside of another program. Hereafter, for simplification, we shall refer to that procedure as the ''SHELL". The SHELL: A Global Tool for Calling and Chaining Procedures in the System Wait, what is procedure? supervisor? console? interface? To make you understand these meanings: computers run instructions in a logical order, most commonly (from the era of punch cards) from top to bottom. That's why we call these ordered set of instructions as procedures. You can call them as subsets of computer algorithms, though. Next, just like real-life supervisors, supervisors handles the execution of these instructions to prevent some technical conflicts like dividing numbers by zero. The console is all the physical buttons and switches which humans can use to communicate with the computer (today, they are completely replaced with keyboards and touch screens). And interface is a way for computers to pass information between computers, programs/procedures, or with humans (hence the name, User Interface (UI)). The SHELL here is neither an acronym or backronym. It is a metaphor of an outer part of the computer system that is intentionally exposed to interact with the user. The SHELL was invented during the early days of command-line interfaces, and that's why people often exchange the term shell with command-line. Note that, the command-line is the interface, aka. how do you interact with the computer system, but the shell is the program that acts at the computer end of that interface, or in other words, who are you writing these commands for. So, how about the Shells of the Bearers of the Shells? We name ourselves the Bearers of the Shells because we own and use multiple computer shells to achieve our goals. In reality, we mostly use Fish, PowerShell, Python (if you consider one), and ZSH. However, we also took the word "shell" differently, which now means "the spherical 🔮 thing we have in our heads". Those spheres are then decorated with symbols commonly found in computer shells: (>_ ) from DOS and Windows, ($_ ) from Unix and lookalikes (Linux, BSD, etc.), and (#_ ) for Unix that belongs to a special user named root. You'll also see that those symbols act as our faces, because we're not just interacting with those computer shells, we are the computer shells! So, in conclusion, we are BOTS because we wear these 🔮 things, and we're the ambassador of computer systems, ready to help people who are using us.
The few odd things found on Hacktoberfest 2022's presents.
Universal.css: The Tailwind CSS that never was.
Are you tired to organize your CSS class names? Check out Universal.css, the only CSS you need. It's available for just under 5MB storage, but it's really worth the size. (Just don't use Tailwind CSS, it's a cheap ripoff of Universal.css).
Re: The (extremely) loud minority (of JavaScript and Typescript developers)
Actually, there’s a DEV.to post named “17 Compelling Reasons to Ditch TypeScript for JavaScript”, only to be defeated by another post named “18 Reasons to Use TypeScript Since Yesterday”. I’ve documented all my criticisms here at “Code, not Content”. Since you specifically mentioned Twitter as the main source for these loud posts, I can say that many of them are just wanted to verify their status as a TS developer. I also see many of them ended up freelancing or worked on tech startups, which aren’t included in W3Techs list. When it comes into the big web industry, WordPress might won the “icing on the cake” by being able to afford a simple (despite themes and plugins are making it more complex), open CMS for managing content. Even many global news websites are still using that instead of fancy SPA. But successful stories, as told by the top ones who are using TypeScript, convinced people that every website should be rewritten in TypeScript. That's unfortunate, especially when simpler solutions do exist. For devs, code might be important, but for people, content matters.
Twitter-active Cupertino productivity fan name needed!
Should developers generalize or specialize?
The skill and career journey I've adopted so far is the diamond approach: As a beginner, it's okay to specialize on one thing before moving to others. But specialization should have its limits. I started myself in late-2013 as a (HTML and CSS) web developer, learned more about the DOM, and responsive design, before generalizing myself to use more and more web libraries and frameworks. Getting yourself in either generalization's or specialization's comfort zone is risky, because: Generalization could mean that you've tried all of these technologies but still have little average experience on these, and Example: I've learned today's great web frameworks (React, Vue, Svelte, CodeIgniter, Laravel, etc.) but I still don't understand how to optimize my apps created by each framework Specialization contains a risk of working with aging pieces of tech Example: I'm doomed as a desktop app/program developer; people are care those smartphones and tablets when I can just make Java-based desktop programs. This diamond approach is indeed a repeating pattern. After re-specializing yourself from generalization, you'll need to re-generalize again before specializing on another one. This is great because one day, you'll become a generalist who also specializing on each fields. Or in other words, a multiple-T-shaped developer, or even a comb-shaped one. You can learn new, emerging things very quickly due to your past, specialized experiences. And you'll be different to those who just either want to stick with one or two languages/frameworks or just want to learn as many things as possible.
15,000 emails. 8 months. All delivered to you from the only one roothouse.
It was June 2021 and we were trying to send emails for those joining HISHOT 2021, an online community seminar held by the Computer Science Studient Association of BINUS University (HINTI BINUS). If we decide to use Gmail, well, one day Google could ban us if we send more and more automated emails in the long-term. Good thing that the web hosting service behind himti.or.id also offers a SMTP email service, which we can use instead to send to them on behalf of [email protected]. The web hosting provider rate-limits the inbuilt SMTP service to the maximum of 200 emails per hour. But just to be safe, we're just going to use a half of them. That means we have to schedule the emails to be sent at a constant rate. Sure, we can use a MySQL database to store the pending emails, but Reinhart doesn't want to run and cron PHP scripts inside the remote server. At the end of the day, he decided to write a Python script and run them on his own PC. But one question remains. Is there a better way than just letting that big laptop to run scripts 24/7? Do we have a more energy-efficient way to do this? Apparently before Reinhart got his first Raspberry Pi 3 as a birthday gift and later bought an Orange Pi Zero, and they're both unused. So we decided to try the smaller house, and oh boy, we made it root. Hey, you may already read about Shift's log about sending emails before. But sure, everyone's working to get the job done. Here we fetch all draft messages to the roothouse befor asking her to deliver one-by-one. And spoiler alert, the roothouse is getting bigger! Version 0: A greedy Python script. We first iterated on creating a simple Python script which does these things: Get a list of draft emails, straight from a remote MySQL database For each emails, send them via SMTP Simple, right? The original script really worked well. However, another problem came when the script needs to fetch all of the pending emails. Or in other words, if there are 1,000 email messages waiting to be sent, the script horribly fetches ALL of them before being able to be sent. Well, that's too much and we should fetch them little by little. Not to mention there could be some messages which we need to prioritize for and to let Shift recover again when the script crashes. Version 1: A slightly efficient script. Then we decided to send emails by priority levels by upgrading the database and our SQL query. And as expected, this version worked even better especially when queuing low-priority emails (e.g. attendance receipts and e-certificates). We also tried to fetch at most 50 pending emails per batch, before sending and re-checking them, so the overall delivery time can be significantly improved. Additionally, we started to accept and parse email messages written in Markdown so yeah, we can finally make your next emails from HIMTI less boring. HIMTI's Unified Registration system also used Markdown for creating event announcements, and we're very happy to integrate that into our emails. This version worked well until we had to think about delivering e-certificates for HISHOT 2021. No, not by sending a OneDrive or Google Drive link to the list of e-certificates, but attaching them directly into the message. So here comes Version 2. Version 2: Because e-certificates broke our script. Sending e-certificates are much slower than regular, plaintext/HTML/Markdown emails for one reason: they're huge. There are two main strategies for this, whether the script is instructed to fetch the file locally and add them to the email list, or by including the entire attached message into the database. We ended up choosing the latter one because that means we can also send anything beyond images and e-certificates. So as usual, we upgraded the database and script, but then the hosting provider blocked our websites for storing too much data inside the database. That's quite a bummer, though, that we have to regularly clear sent emails from the database to be able to schedule new emails for more people. Version 3: Concurrency. As this great email delivery solution for HISHOT was adopted to more HIMTI events, including TECHNO 2021, COMPUTERUN 2.0, and HIMTI ELECTION 2021, we realized that we have to upgrade our infrastructure to be able to send more emails, for more events and people! We also realized that not every message have to be sent over the himti.or.id SMTP server. For example, internal message for event committees when a new participant have registered and paid for the event. That's why we decided to use Shiftine's private email address to send these committee messages. And more than that, we start to use GitHub Actions to help us check emails more regularly, being able to sleep() when there are no more emails to send. We can also prioritize and strategize the delivery of different emails from separate events, like sending HIMTI ELECTION receipts during the day and COMPUTERUN 2.0 reminders during the night. Some personal reflections. Yeah, that was great! I was able to share my "can't hibernate, i'm overpowered" spirit to help people in the real world. And as I now help to maintain BINUS Today's list of articles as part of my chore, seeing those sent emails feels like a nostalgia for me. Oh, right, you can check out our final code at https://github.com/alterine0101/emailer.py/.
