💾 Archived View for erock.io › atom.xml captured on 2023-01-29 at 02:28:59.
⬅️ Previous capture (2022-07-16)
-=-=-=-=-=-=-
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<id>gemini://erock.io/</id>
<title>erock's gemlog</title>
<author>
<name>erock</name>
<email>gemlog@erock.io</email>
</author>
<updated>2022-07-13T04:06:52Z</updated>
<link href="gemini://erock.io/" rel="alternate"/>
<link href="gemini://erock.io/atom.xml" rel='self'/>
<entry>
<id>gemini://erock.io/2022/07/12/internet-points/</id>
<link href="gemini://erock.io/2022/07/12/internet-points/" rel="alternate" />
<title>internet points</title>
<updated>2022-07-12T00:00:00Z</updated>
<content>I've spent the past decade chasing internet points on Reddit, Github, and Twitter. I've found that focusing on internet points doesn't actually yield favorable results. I spent so much time trying to figure out what other people want to see that I've lost sight of what I want to see.
In the early days of reddit I used to spend hours constructing well thought out and cited posts. I wanted to get karma because it somehow validated how smart I am. Whenever I would get downvoted or receive a confrontational response, I would feel deflated. Negative responses would scare me. It got to the point where I would feel an intense amount of anxiety whenever I opened my inbox. What are they going to say about my post? Was it well received? I would obsess over the points I had accrued over time. I justified that this was a training process to figure out how to construct well written posts. To some extent I think that's true, but the reality is my focus on internet points ultimately led to an unfavorable result. I was merely trying to please people while sacrificing my own thoughts, ambitions, or desire to express my mind.
Then along came Github. Github stars are a seductive drug. The more stars you have the more internet clout you have as a developer. The issue is compounded by the fact that popular projects open doors for you as a software developer. I've spent years chasing stars only to slowly realize yet again that internet points mean nothing. They say nothing about you or the project you are working on besides a popularity contest. Why do I want to be popular so badly? Why do I always fall short of these popularity contests?
Recently I've come to the realization that social networking sites are reinforcing this need to be popular and now that I've put a name to the concept I've been trying to recuse myself of it entirely. It's tough because it feels like you can't create software projects without being on Github. Sourcehut has been a great outlet for me lately. The whole philosophy behind Sourcehut is really resonating with me as I lash out against all things social networking.
Who knows, maybe this is just an ad-hoc rationalization for why my projects never seem to gain any traction.
Even if that is true, I know that focusing on internet points is counter-productive. From now on I'm only going to build projects or products that I want to use.
</content>
</entry>
<entry>
<id>gemini://erock.io/2022/06/14/interview-at-hashicorp/</id>
<link href="gemini://erock.io/2022/06/14/interview-at-hashicorp/" rel="alternate" />
<title>my interview experience with hashicorp</title>
<updated>2022-06-14T00:00:00Z</updated>
<content>I figured I would write about my relatively recent experience interviewing at Hashicorp.
I had a friend who referred me to an open position at Hashicorp and figured I would apply just to see what the job would be like. For context, my current employment is great and I had zero sense of urgency to move to a different company. Having said that, I figured it might be fun to go through the interview process at a well known SV tech company and who knows, maybe it would be something I was really excited about.
Spoiler: I didn't make it very far.
I had a very nice chat with one of their recruiters. Everything seemed to line up -- they almost always do at this stage -- and so I moved on to the next part of the interview.
The next stage was to chat with a product manager. I liked him, we got along very well and seemed to have a great conversation. It eventually came out that the position I was applying for was primarily front-end (which is a strength of mine) and their FE stack is all ember.js (not a strength of mine). I'm not sure if this part of the conversation took a turn for the worse, but he didn't really ask me any follow up questions about my experience with ember. I did remember saying something to the effect of:
> The recruiter mentioned that I could use react for the technical challenge so I figured at least some of the codebase was using react.
To which he responded:
> No it's all in ember.
At this point I definitely lost some interest in the position and upon reflection wonder if my demeanor changed and that's the reason for the rejection? Regardless, I figured they were not picky about technology choices since they offered alternatives to ember during the technical interview. The interview ended and I went about my day.
I didn't hear anything from them for a couple of days -- which is usually a bad sign when they have a team dedicated to hiring. I eventually received a call from the recruiter saying they were *not* going to move me forward to the next step. I asked for feedback, she didn't have any to give. Whenever you get rejected it's never a great feeling but I always force myself to perceive the experience as an opportunity to improve. Whether it's my communication style, the way I answered questions, or the questions I should have asked. I want to be my best self and feedback, even though it's hard to hear sometimes, is an invaluable aspect of self-improvement.
I decided to reach back out to my friend who works there to let him know I was rejected. I indicated that they didn't have any feedback for me and he took it upon himself to figure out what happened. A couple of hours later I received a message:
> So they didn't want to say why they rejected you but you should feel free to apply again at a later date.
I don't get why companies are so apprehensive to provide constructive feedback. Simply "we are looking at other, more qualified applicants" or "you are a react fanboi" would be sufficient. There was no reason provided and they were being a little secretive about it. Maybe it's about liability or they don't want any opportunity for the applicant to be confrontational? It was nice to get a rejection phone call even though an email would be sufficient since it was pretty clear that they wanted to cut off all further communication.
Hashicorp is doing some amazing things in the open source community and I would have enjoyed being part of it. Having said that, after the two phone calls I had with the company, it was becoming more clear that this wasn't the right company for me. It was too large of an organization for my taste and the entire process felt very rigid. Also the way they responded to me asking for feedback was awkward and off-putting.
To Hashicorp and other companies that are hiring: Please provide constructive feedback to your applicants. Even if they get the job, providing constructive feedback is such a valuable mechanism for growth on both sides. I learn a lot both when providing and receiving feedback. When providing feedback, it requires me to really understand my rationale and clearly communicate it. When receiving feedback, it requires me to have patience and mental dexterity to be better.
</content>
</entry>
<entry>
<id>gemini://erock.io/2022/06/03/github-as-social-network/</id>
<link href="gemini://erock.io/2022/06/03/github-as-social-network/" rel="alternate" />
<title>On github as a social network</title>
<updated>2022-06-03T00:00:00Z</updated>
<content>Ever since I became jaded by social networks, I've been examining the sites I visit and why I continue to visit them. We all know the addictive behavior driving social networking "engagement." Ever since I first discovered facebook I have been fighting against the constant drip of accumulating social currency. Slowly I began to realize that these social networking sites were echo-chambers that really didn't mean much at all. When you talk to people in person, there's a sense of restraint. In person, people have manners, can read the room, and understand what they should vocalize to their listeners. Perhaps most important of all, they know when to keep thoughts to themselves.
It was only on these social networking sites, where people have a podium, that I noticed quite a change in discourse. All of a sudden, you could read family and friends' thoughts on all types of subjects that are never uttered in person. Through these sites, I learned that some things are best left unsaid. And so I left.
However, there's still a few social networking sites that I use. There's one in particular, that is cloaked under the guis of productivity. Hidden behind both my personal and professional life. It's one of the first pages I open during the day, and one of the last ones to be closed before bed. Notifications from this site are important because they could be a ping from a colleague who needs me to review what they wrote. Or it could be a new question raised on one of my projects. Github is the worst kind of social networking site. Like a virus, it has infected my mind and is constantly getting me to engage with it. It's a social networking site that I have to use for work. Software engineers stand no chance against github. How did a site with such good intentions turn into one that preys so easily upon our weaknesses?
"Github is the software engineer's resume, it will help you get a job" That's what I have convinced myself is true. Is it actually true, though? I imagine it's true for the people who have accumulated a lot of social currency. However, it has been my experience that many companies do not even look at your resume. No, these companies have a rigid process for potential employees and they rarely deviate from the norm.
Now, with github sponsors, it's easier than ever to become popular and get paid to work on open source projects. Popular, being the operative word. There's even more reason to use github because the platform could help suppliment your income.
Why do I get so excited when I get stars on my projects hosted on github? I am constantly trying to come up with new projects to build, but do I actually want to build them? Or do I just want social currency? I'm not sure I can tell the difference anymore.
Github isn't just a code repository, it's a social networking site. The network effect makes it really hard to host other open source projects anywhere else. I catch myself typing in a somewhat generic phrase, looking for an OSS project, and append the search with "github." Ultimately, github makes it easier for people to discover your work. People that want to share their work and have people use it gravitate towards github. No other code repository site has as much mindshare as github and it's all thanks to the human desire to accumulate and compare with peers. Humans yearn for social clout and recognition.
Why was my judgment so clouded?
I really like sourcehut[1] and will be moving everything there. There are no "engagement" features like stars or trending projects. Drew, more than anyone, has made me realize that you don't have to participate in social networking in order to have people use your projects.
=> https://sr.ht sourcehut[1]
For now, I'm going to maintain a mirror on github of my popular code repositories, but I think I need to start distancing myself from the most addictive social network in my life.
</content>
</entry>
<entry>
<id>gemini://erock.io/2022/06/02/on-language-package-managers/</id>
<link href="gemini://erock.io/2022/06/02/on-language-package-managers/" rel="alternate" />
<title>On language package managers</title>
<updated>2022-06-02T00:00:00Z</updated>
<content>The more I read about supply chain attacks and security issues revolving around language package managers, the more pressing I think this issue has become.
> They join a growing club of broken-by-design package managers which publish packages uploaded by vendors directly, with no review step, and ship those packages directly to users with no further scrutiny.
=> https://drewdevault.com/2022/05/12/Supply-chain-when-will-we-learn.html
On one hand, I totally agree with Drew here. The fact that there are virtually no security measures in place for publishing packages to a registry is a source of our problems here.
However, I'm also of the opinion that regardless of what protections a package manager puts into place for consumers, the ultimate responsibility falls on the consumer to properly vet their dependencies. I'm all for having standard practices put into effect to make it easier to follow a secure path, but that's about where I draw the line.
I think having a third-party review the package before it can be listed in the registry is fine. However, there still needs to be an easy way to side-load those packages then. There have been many times where I wanted to publish a package just to proply test it works properly end-to-end.
I know Drew uses golang quite a bit, I wonder what he thinks about the no-registry paradigm that golang employs. I think it's even easier to use than npm, but that comes with a big downside: there is no friction between creating a git repo with a golang package and a consumer using it. No review step and no further scrutiny.
I've been trying to learn more about products or services that help prevent supply chain attacks and compiled a meager list here:
=> gemini://lists.sh/erock/bookmark-supply-chain-security
I really wonder if services like these will ever get traction. The reason why there's a blossoming ecosystem revolving around popular package managers is because they lower the barrier to entry to consume code. Adding this security step sounds great but in reality, I really wonder how many people will use it. I guess one could argue that TLS is equally a pain and we have been seeing pretty awesome tooling around that to make it as simple as possible.
As an aside, I started using caddy instead of nginx primarily because of its auto-tls functionality.
If anyone else has any thoughts on how to help prevent supply chain attacks, I'd love to read about them. I'm too early in my research to provide any concrete thoughts of my own. I do think regardless of what is proposed, it needs to strike a balance between easy package publishing and providing the tools for a package developer to be successful without jumping through a dozen hoops.
</content>
</entry>
<entry>
<id>gemini://erock.io/2022/05/28/reply-error-handling/</id>
<link href="gemini://erock.io/2022/05/28/reply-error-handling/" rel="alternate" />
<title>reply -- error handling</title>
<updated>2022-05-28T00:00:00Z</updated>
<content>> That is, the function is able to return either the intended return value or the error. Zig also has tagged unions, which in code look like an enum wrapping a union. This is what is really meant by the term Algabraic Data Types.
=> gemini://gemini.hitchhiker-linux.org/gemlog/re_error_handling.gmi
After reading this post I felt the urge to mention that Typescript also has the same concept, although it's called a discriminated union.
=> https://www.typescriptlang.org/docs/handbook/unions-and-intersections.html#discriminating-unions
Recently I've been doing a lot of software development in golang and this is something that was missed. It looks like there's an outstanding github issue[1] discussing the addition of discriminated unions to golang.
=> https://github.com/golang/go/issues/19412 [1] sum type
I love discriminated unions in Typescript. Sometimes I wish there was a more standard way to utilize them in the js ecosystem. At least in typescript, there's nothing enforcing error handling via a disciminated union for return types.
I always liked the idea of a maybe type[2] but never end up using it in my code.
=> https://github.com/chrissrogers/maybe#readme [2] maybe npmjs
Wikipedia article on algebraic data types for those interested in learning more:
=> gemini://gemi.dev/cgi-bin/wp.cgi/view?Algebraic%20data%20type
Overall I often find myself learning new concepts from the JS ecosystem than any other language. There are some really bright minds working in that ecosystem, producing fantatic ideas. All of this is to say that js gets a lot of hate but there are some good parts to it as well.
</content>
</entry>
<entry>
<id>gemini://erock.io/2022/05/21/shifting-away-from-spa/</id>
<link href="gemini://erock.io/2022/05/21/shifting-away-from-spa/" rel="alternate" />
<title>reply -- the balance has shifted away from SPAs</title>
<updated>2022-05-21T00:00:00Z</updated>
<content>A recent article popped up on hackernews[0] that I figured I would respond to here.
=> https://news.ycombinator.com/item?id=31459316 [0] The balance has shifted away from SPAs
# New frameworks are focusing on MPA + 0kb JS by default
I definitely see a trend where more and more web frameworks are trying to leverage multi-page applications with minimal or no javascript on the front-end. I welcome these changes because not everything needs to be an SPA. I recently built lists.sh[1] which doesn't have any javascript in its stack. Everything works perfectly fine a simple document browser. It was a lot of fun to build and didn't require any heavy lifting on the front-end. But here's the thing, it didn't require any interactivity. One of its features was no javascript. At the core of the site is a blog. Blogs do not need javascript and in fact, tend to make the reading experience worse. This is one reason why I'm enjoying gemini so much. Gemini is great for what it is: a document browser.
=> https://lists.sh [1] lists.sh
In the comments someone mentioned the concept of holotypes[2], which classifies each use case of the modern browser in a category.
=> https://jasonformat.com/application-holotypes/ [2] application holotypes
Some categories are better suited as an SPA vs an MPA. So let's organize the list that way:
## SPA
curl https://nvim.sh
nvim.sh - neovim plugin search from the terminal
api description
https://nvim.sh help
https://nvim.sh/s return all plugins in directory
https://nvim.sh/s/:search search for plugin within directory
https://nvim.sh/t list all tags within directory
https://nvim.sh/t/:search search for plugins that exactly match tag within directory
powered by: https://neovimcraft.com
source: https://github.com/neurosnap/nvim.sh
Finding a plugin using `/s/:search` will look something like this:
$ curl https://nvim.sh/s/git
Name Stars OpenIssues Updated Description
sindrets/diffview.nvim 671 7 2021-12-17T16:10:43Z Single tabpage interface for easily cycling through diffs for all modified files for any git rev.
tveskag/nvim-blame-line 121 1 2021-07-27T18:59:55Z A small plugin that uses neovims virtual text to print git blame info at the end of the current line.
TimUntersberger/neogit 1056 57 2022-01-08T08:04:27Z magit for neovim
tanvirtin/vgit.nvim 265 12 2022-01-08T06:55:57Z Visual Git Plugin for Neovim
kdheepak/lazygit.nvim 255 7 2022-01-04T23:44:54Z Plugin for calling lazygit from within neovim.
Iron-E/nvim-highlite 134 1 2022-01-06T18:55:05Z A colorscheme template that is "lite" on logic for the developer.
onsails/vimway-lsp-diag.nvim 71 5 2021-12-28T07:58:29Z Live render workspace diagnostics in quickfix with current buf errors on top, buffer diagnostics in loclist
onsails/diaglist.nvim 71 5 2021-12-28T07:58:29Z Live render workspace diagnostics in quickfix with current buf errors on top, buffer diagnostics in loclist
lourenci/github-colors 29 1 2021-10-04T13:53:35Z Yet another GitHub colorscheme
lewis6991/gitsigns.nvim 1066 19 2021-12-30T11:54:10Z Git integration for buffers
tversteeg/registers.nvim 335 4 2022-01-03T08:48:42Z đź“‘ Neovim plugin to preview the contents of the registers
f-person/git-blame.nvim 247 4 2022-01-04T23:20:49Z Git Blame plugin for Neovim written in Lua
ruifm/gitlinker.nvim 148 7 2021-12-23T15:11:12Z A lua neovim plugin to generate shareable file permalinks (with line ranges) for several git web frontend hosts. Inspired by tpope/vim-fugitive's :GBrowse
projekt0n/github-nvim-theme 559 5 2022-01-08T11:29:31Z Github theme for Neovim, kitty, iTerm, Konsole, tmux and Alacritty written in Lua
winston0410/range-highlight.nvim 97 5 2021-08-03T07:19:30Z An extremely lightweight plugin (~ 120loc) that hightlights ranges you have entered in commandline.
m00qek/plugin-template.nvim 29 0 2022-01-05T20:16:10Z A template to create Neovim plugins written in Lua
rktjmp/highlight-current-n.nvim 16 1 2021-10-26T12:16:53Z Highlights the current /, ? or * match under your cursor when pressing n or N and gets out of the way afterwards.
Searching for a plugin uses a fuzzy matching algorithm Levenshtein distance to find the best matches based on the name and description. => https://en.wikipedia.org/wiki/Levenshtein_distance Levenshtein distance Since all of the plugins are tagged, you can also search for plugins matching the tag with `/t/:search`
$ curl https://nvim.sh/t/comment
Name Stars OpenIssues Updated Description
folke/todo-comments.nvim 607 24 2021-12-11T09:13:48Z âś… Highlight, list and search todo comments in your projects
numToStr/Comment.nvim 572 8 2022-01-02T12:51:22Z :brain: :muscle: // Smart and powerful comment plugin for neovim. Supports treesitter, dot repeat, left-right/up-down motions, hooks, and more
b3nj5m1n/kommentary 471 13 2021-12-03T13:54:42Z Neovim commenting plugin, written in lua.
terrortylor/nvim-comment 207 7 2022-01-04T23:21:12Z A comment toggler for Neovim, written in Lua
danymat/neogen 149 6 2022-01-08T12:34:58Z A better annotation generator. Supports multiple languages and annotation conventions.
winston0410/commented.nvim 93 2 2021-11-14T06:00:20Z Neovim commenting plugin in Lua. Support operator, motions and more than 60 languages! :fire:
glepnir/prodoc.nvim 42 0 2021-01-23T07:01:54Z a neovim comment and annotation plugin using coroutine
s1n7ax/nvim-comment-frame 37 0 2021-09-14T06:54:29Z Detects the language using treesitter and adds a comment block
gennaro-tedesco/nvim-commaround 33 0 2021-12-16T11:39:07Z nvim plugin to toggle comments on and off
The data source for this service is https://neovimcraft.com and it is
automatically refreshed once per hour.
I'd be happy to read any feedback or suggestions to make this service even more
useful!
</content>
</entry>
<entry>
<id>gemini://erock.io/2021/11/01/framework-vs-mbp/</id>
<link href="gemini://erock.io/2021/11/01/framework-vs-mbp/" rel="alternate" />
<title>framework vs mpb</title>
<updated>2021-11-01T00:00:00Z</updated>
<content>Suddenly, I'm awake. I head over to the kitchen to find my work laptop to start
the day. I pick up my 2019 15" macbook pro. The cold metal grazes my arm as I
carry it to my desk. I grip the binding like a book before laying it down in
front of me. The edges are round and it feels like a contiguous hunk of metal.
With one hand, I can open the monitor.
Whether you like Apple or their ecosystem or not, the macbook pro is _the_
premium laptop. I've been searching for years to find something that can come
close to it within the linux ecosystem.
Most of my laptops have been loaners from work and they have all been macbook
pros. In the beginning I absolutely loved it. I basically get a free premium
laptop everytime I get a new job. However, as the years pass, the more I've been
getting bored with the Apple ecosystem. OSX is stable and it works reasonably
well for a software engineer. But I like to tinker. I like to make the tool work
for me, not the other way around.
Whenever I look at other laptops, my internal monologue is always asking: "but
how's the trackpad?" This question causes me to hesitate when looking at other
laptops. I know what I'm going to get with a macbook pro. Premium build,
speakers, monitor, trackpad, and battery life. Some of these features are easy
to compare without having used the laptops, others are impossible.
I love the idea behind the framework laptop. If you're looking at this review,
you already know why it's a potentially industry-changing laptop. I finally
caved and bought it a couple months ago and I finally received it in the mail
last week.
When attempting to make this decision, I was searching online for comparisons
specifically to macbook pros. So, in this article, I want to compare the two
laptops in hopes that I can convince people that it does in fact compete with
the macbook pro.
For these comparisons:
- I'm going to set the scale between -1 and 1.
- The macbook pro will be set to 0 for all categories.
- If a score is less than 0, then it is not as good as the mbp.
- If a score is greater than 0, then it is better than the mbp.
- If the final score for the framework is a 0 then the laptops are very close to
identical.
Let's start with the question I posed above
# Trackpad (-0.2)
After all of my research, this was the one feature that I gambled on. I had no
idea what to expect. I have been using macbook pros exclusively for the better
part of a decade so I didn't know what to expect. All the other windows laptops
I have tried had garbage trackpads. I felt an overall lack of precision when
using them.
I'm happy to announce that I don't notice a huge difference between my macbook
pro's trackpad and this one. It's precise, it worked well out-of-the-box on Arch
using sway, and is good enough. To be clear, the mbp's trackpad is superior,
especially with its gestures so tightly integrated into OSX but for basic mouse
functionality, it works great.
# The Feel (0.1)
This laptop feels like a hunk of metal. I was very surprised at how nice it
feels to carry. It's difficult to lift the lid with one hand but it is doable.
The monitor hinge feels a little loose. When falling onto the couch while
holding the laptop, the mbp's screen won't move from its original position,
whereas the framework's will. Using my finger to slightly tap the framework
monitor will cause it to shake quite a bit, whereas the mbp will barely budge.
Me: "What game are you talking about?"
John: "It's a computer game called Graal Online."
Connor: "It's like a multiplayer zelda game."
I ran home and figured out how to install the game. Eventually I logged in and met up with John and Connor. They showed me around the game and helped me get hearts and weapons. I was having a blast. This was one of the first online multiplayer games I have ever played and needless to say, I was hooked from the beginning. There was one aspect of the game that was really interesting. It wasn't just an adventure game, it was also a builder game. I think of it like minecraft but with 2d zelda graphics. People could build levels and then upload them to the game server so other people could play on your levels. Another aspect of this game was playerworlds. People could purchase their own server and then build their own worlds. Not only could players build levels, but there was also a scripting language (GScript) to build NPCs, events, etc. The creators of the playerworlds would also hire other players to help them build the world. These were referred to as "Staff." They had their own special guild tags so everyone would know that they were staff members. This usually came with special abilities, access to hidden levels, as well as a special chatroom for all the staff members to talk. One day, John decided to show me what he built. He built a house that him and his friends could go to and hang out. I was really impressed. It was clear he spent a lot of time building it and was really proud that he managed to get it uploaded to the playerworld for everyone to see. Some time had passed and I was getting really into the game. I started to learn more about how the game worked and more importantly I started to learn how exclusive and how powerful you can be as a staff member. Staff members would walk through walls, teleport to any level, and have abilities no one else had access to. Not to mention the really sweet tags next to their names. The easiest way to become a staff member was to have a marketable skill and willing to help them build their playerworld. Here are the common positions: - LAT (Levels Administration Team) - NAT (NPC Administration Team) - GAT (Graphics Administration Team) - SFX (Sound effects) ## The event I decided that I would apply for the LAT position since the playerworld I played on was hiring. They wanted to see an example of a level I built. I don't know what came over me but I decided to show them John's level. The staff member teleported us to the level and he took a look around. He was as impressed as I was with the level and decided to give me the position. Needless to say I was ecstatic. I was part of the exclusive club. I was walking through walls and teleporting all over the place. Not only that, but I got access to the entire world and could see how the playerworld operated. I was having a blast. A week or so later I get a message from the person that hired me.
Staff: "Hey Erock, we need to talk."
Me: "Okay?"
The staff member teleports me to where he was. It was John's house that I
claimed to be my own. He also wasn't alone ... John was also there waiting for
me. At this point I'm freaking out because it became clear in that instant that
I had been caught as a fraud.
I don't know how, but John figured out that I said his house was mine in order
to get the LAT position and he told the staff member. I was mortified.
I was immediately stripped of my LAT position along with all of its trappings.
After that embarrassing event, John and I were never really the same again. I
never apologized for what I did and we pretty much stopped hanging out. I really
liked John. I looked up to him. He was one of the gifted kids. He was in honors
classes and the REACH program that always seemed to have the coolest rooms in
the school. I made a stupid decision and never recovered from it.
After I was stripped of my LAT title and outed as a fraud I continued to play
Graal. I continued to try to prove to myself and anyone else that I wasn't a
fraud. I eventually became LAT Lead on multiple playerworlds and built a
reputation for building great levels. By this point years have gone by and John
and Connor have long stopped playing the game.
I know it sounds silly, it's just a game, right? But I learned a valuable lesson
that day about pretending to be someone I'm not. I learned that there are no
shortcuts in life and that I have to work hard for the thing I want in life.
20 years later and I still reflect on that life event.
## My apology to John
Dear John,
I've always wanted to apologize for what I did. At the time, I wanted something
so badly that I was willing to lie and cheat to get it. Claiming your level as
my own was the quickest way to getting what I wanted. I was immature and didn't
fully understand the ramifications of my actions. I just want to let you know
that I've never forgotten what happened and I still haven't really forgiven my
13 year old self for being so selfish.
I wish I had the courage and maturity to tell you this when we were 13. I wish
that I had the clarity I do now to confront my own insecurities and try to
salvage our relatively new friendship.
</content>
</entry>
<entry>
<id>gemini://erock.io/2021/03/27/my-love-letter-to-front-end-web-development/</id>
<link href="gemini://erock.io/2021/03/27/my-love-letter-to-front-end-web-development/" rel="alternate" />
<title>my love letter to front-end development</title>
<updated>2021-03-27T00:00:00Z</updated>
<content>Building front-end web applications has been my primary job for the past 5
years. Having a pulse of the current javascript ecosystem is exhausting. The
ecosystem is under constant churn where new tools are being built at a rapid
pace that radically changes the way we build web applications. There's also a
lot of tools in our stack in order to build a production-grade web application.
How did we go from being able to inline javascript in our HTML to having a build
pipeline that involves making a handful of tooling decisions before a single
line of javascript code can be written?
Software engineering as a profession has been around for decades, there are
dozens of modern programming languages, thousands of tools and frameworks to
help satisfy our business requirements for a product or service. After hundreds
of thousdands of minds building software and learning from previous mistakes,
why does it feel like the front-end is churning the tech it uses so much? Why
does it seem like the front-end is such a mess? From fiasco's like `left-pad` to
tooling churn, front-end development stands alone as the black swan in software
development.
I'm constantly reading on hackernews and the ilk that people who consider
themselves competent software engineers -- generalists even -- avoid front-end
web development like the plague. Why do so many professional engineers have
disdain for front-end development?
The answers to these questions are why I love front-end web development.
Javascript sucks and that's why it's amazing. Let's explore this ecosystem
together while I try to convince you why front-end development is so exciting.
# A black swan
Javascript has a very unique set of challenges that differentiates itself from
the rest of the programming world. The primary driving factor for its unique
position is javascript is downloaded on the client's browser. Languages that run
on the server, for example, don't need to send code that it runs onto client
machines, they merely respond to requests made from the browser. The computation
runs on the server. Traditional desktop applications only require the client to
download the code or executable once to run the application. For front-end
development, it's downloaded everytime. This is the key requirement that
differentiates front-end development from the rest of its comrads:
> Front-end development needs to consider total code size.
Where other slices of the tech stack don't need to worry as much about code
size, it's a primary consideration for us.
What's the side-effect of this requirement?
- Small libraries are preferred over large ones
- A lot of tooling focuses on reducing code size
Let's look at these side-effects to better understand how it affects the
ecosystem.
## Small libraries are preferred over large ones
Because code size matters, javascript libraries are hyper-focused on delivering
the most powerful set of functionality in the smallest amount of code possible.
When I think of modern javascript libraries, I'm reminded of the unix philosophy
of doing one thing and do it well.
> Javascript libraries do one thing and do it well out of necessity
This is taken to the extreme when there are libraries that are one line of code.
`is-promise` is a popular one-line javascript function that was infamous for
breaking a ton of applications and libraries because it introduced a regression.
function isPromise(obj) {
return (
!!obj &&
(typeof obj === 'object' || typeof obj === 'function') &&
typeof obj.then === 'function'
);
}
`left-pad` was another famous example of a tiny library causing projects all
over the world to fail to build.
It seems silly, but this side-effect is perfectly explained by the unique
requirements of front-end web development.
## A lot of tooling focuses on reducing code size
From code minification to tree-shaking, there's an abundance of tools that help
reduce the overall filesize of our javascript code that gets downloaded over the
wire. The front-end development build pipeline needs to spend time figuring out
what code is actually being used in an application as well as figure out how to
mangle it to be as small as possible. I've never worked on another project,
outside of front-end development, that needed to care so much about code size.
For example, projects that use python don't have to consider the ramifications
of bringing in large dependencies. `numpy` is a very popular pypi package for
data science and statistics. Adding that one package to your project will
increase the total code footprint by ~30MB. Can you imagine the vitriol
front-end developers would receive if they had a javascript bundle size of even
a fraction of that? It would be reprehensible.
Sometimes we _do_ need to pull in large libraries because of how useful they are
to us. They save hundreds and thousands of person hours and are cost effective
to the business. We have to get creative and that is illustrated in the
incredible amount of tooling in the javascript ecosystem. The ecosystem is
constantly churning through tooling libraries in order to satisfy this one
requirement.
# One ring to rule them all
There is only one programming language that we can target for browsers:
javascript. We have other languages that can target javascript, but the end
result must always be javascript -- for now.
> For better or worse, thousands of developers **must** use javascript
Since there is effectively only one language ecosystem, there is an immense
amount of creativity and labor hours put into solving its toughest problems. The
ecosystem is under constant churn because it **needs** to satisfy so many
requirements for a wide range of businesses. If we had the same number of
popular programming languages on the front-end as we do on the back-end, there
would be far less churn within each ecosystem. I would also argue that because
javascript has its faults -- like any language -- there are a lot of incredible
people coming up with ingenious solutions to patch those issues.
> Because developers are forced to use javascript, they are forced to come up
> with creative solutions.
This creativity leads to fantastic and ingenious solutions. It's truly one of
the most vibrant and interesting programming ecosystems to be apart of. In
recent years, there are some tools that have revolutionized javascript. In
particular:
- Typescript
- Prettier
- ESLint
- React (`view = f(state)`)
I would argue that the type system in typescript has contributed to more stable
web applications than any single piece of tooling within the ecosystem. I would
also argue that its type system is superior not in design, but by its
application than any other type system I have worked with.
Prettier is just as good as `gofmt` which is saying something considering
`gofmt` was built by the golang language designers.
ESLint is the best linter I have ever seen in a programming language. There
might be comparable linters in other languages, but I haven't seen any
convincing evidence of them yet.
Everytime I grab another programming language, I miss these three tools almost
immediately. Going to python after working with javascript is like going back in
time in terms of tooling.
I would also argue that React is another library that has completely
revolutionized how to build UI applications. There's a reason why so many
applications are built with electron and I would argue it's not because people
don't know how to use Qt. There's a reason why people don't want to use Qt and
it's because the ergonomics of it pale in comparison to React and the web.
Thinking of the view as a function of state was groundbreaking to the UI world.
# There are many ways to run javascript
Javascript has a specification: ECMAScript. This specification is implemented in
different browsers in subtly different ways. The number of javascript
implementations has been slowly declining over the years since v8 has dominated
the browser market with its speed as well as it server side implementations
(e.g. node). However, the fact still remains: javascript is implemented in
subtly different ways and getting adoption of new features is very slow. Getting
users to update their browsers is a momumental undertaking, one that has plagued
front-end developers for years. The delay from a new feature in ECMAScript to
market-share adoption is on the scale of years, not months. This creates yet
another unique constraint for javascript.
The solution to this problem was two-fold:
- new features -- introduced by ECMAScript -- need to be backwards compatible
- tooling can be created to transpile code from one spec to another
Because the designers of ECMAScript make new features backwards compatible (for
the most part), we can build tooling around converting code from a later
specification to an earlier one. This created a new set of tools called
transpilers (e.g. babel) which would convert ES6 code to ES5.
These transpilers allowed developers to write code in the latest specification
without really worrying about market-share adoption. At the same time, it forced
us to be okay with a compilation step to our build pipeline. This opened the
flood gates for all sorts of tooling. Modern javascript code is compiled and
that's not going away anytime soon. Does it add friction for people trying to
learn the ecosystem? Absolutely, but the benefit is huge.
# Conclusion
Because so many talented people are forced to use javascript, because javascript
has wholly unique requirements, we get the pleasure of working within a vibrant
ecosystem. There isn't a year that goes by without some new innovation that
takes the community by storm. However, at the same time, the ecosystem is
starting to mature. React, arguably one of the most popular javascript view
libraries ever built, has been around for 7+ years now. Typescript is
essentially required for all new projects.
Building modern, production-grade web applications is difficult and there are
times when it seems like all of this tooling really gets in the way. There are
times when I'm sick of re-implementing the same components, dealing with the
minor details of moving pixels on the screen, or satisfying the
similar-but-slightly-different UX of an app that makes abstractions difficult.
However, that's what makes front-end development so interesting. A new project
rarely looks like the last.
If we attempted to replace javascript with some other language, it would still
be restricted by the same requirements that restricts javascript today.
When I think about the challenges that face front-end developers I get excited
to be part of this community.
</content>
</entry>
<entry>
<id>gemini://erock.io/2021/03/04/adventure-into-gemini-as-fe-engineer/</id>
<link href="gemini://erock.io/2021/03/04/adventure-into-gemini-as-fe-engineer/" rel="alternate" />
<title>adventures into gemini as a front-end engineer</title>
<updated>2021-03-04T00:00:00Z</updated>
<content>I wanted to talk a little about my current profession and why the juxtoposition
of it with gemini is interesting to me.
It seems like most people venturing into the gemini space are people who live
inside the terminal and never want to leave. There is also some overlap of
people that have disdain for the modern web because of how bloated websites have
become. With javascript, ads, popups, cookie consent modals, I can hardly blame
people. The modern web reminds of nascars with advertizements plastured on their
vehicles. It seems like every website is trying to monetize itself into silicon
valley stardom and as a result, it has ostrcized its early adopters. The people
begging for a simpler web have lost the battle. Even after many attempts to
bring the web into their terminals (e.g. lynx, w3m) it ends up a hack at best
and at worst completely unusable.
Enter gemini. Gemini is against everything about the modern web and wants to
bask in the nostalgic glow of a past life. A life where documents didn't shift
out from under you. They are static, there's a strict 1:1 mapping between the
gemini page and the number of requests made to the server to render the page.
I'm fascinated by this world because I also live in the terminal, but it's also
my job to build web apps. I've been working as a front-end software engineer for
the better part of 5 years now. I build massive javascript web apps for
companies that are trying to monetize the web. I'm building the demons that
haunt the people that enjoy gemini so much.
I agree with the sentiment behind the need for gemini. I think the web has
transformed into a completely different utility than its original intent:
communicating with people. It still very much is about communication, but its
been co-opted by commercialization, which I think is both good and bad. Billions
of dollars are being made off of voluntarist companies building web
applications. The employees are not working in factories, sacrificing their
health and bodies for a paycheck. The only exploitation of its customers are
data. This is not to say people's data isn't sacred, I just think we need
perspective. The people employed in tech lead relatively comfortable lives, and
I think there's something of value to it. Whether we want to admit it or not, we
are generating value for businesses around the globe and it doesn't appear to be
slowing down.
I guess I've read a lot of comments around the gemini community showing disdain
and vitriol for the modern web, but I have a different perspective. I enjoy the
modern web for what it is just like I'm really enjoying gemini for what it is.
In my next article, I'm going to write about why I love javascript so much and
argue for why you should as well.
</content>
</entry>
<entry>
<id>gemini://erock.io/2021/01/23/docker-disk-out-of-space/</id>
<link href="gemini://erock.io/2021/01/23/docker-disk-out-of-space/" rel="alternate" />
<title>docker in production -- running out of disk space</title>
<updated>2021-01-23T00:00:00Z</updated>
<content>> tl;dr: If you are deploying docker containers to production, be sure to run
> `docker system prune -f` before pulling new images so you don't run out of
> disk space.
When I'm building a new project, I generally learn towards using docker-compose
during development.
=> https://docs.docker.com/compose docker-compose documentation
When coupled with docker-machine I have a quick and easy way to deploy my
containers to the cloud provider of my choice.
=> https://docs.docker.com/machine docker-machine documentation
Overall, it works really well, but there's one important thing to consider when
using docker for production: running out of disk space.
Images, containers, networks, and volumes will continue to grow on a production
VM which will inevitably lead to the hard drive running out of memory. This
seems obvious, but it wasn't obvious to me when I first started using
`docker-machine`.
I recently built a new app (listifi) to google cloud compute and ran into
out-of-memory issues after a bunch of iterations. The default VM only has around
15GB.
=> https://listifi.app listifi app I built
=> https://cloud.google.com
Here's a brief overview of my deployment process:
- Develop using `docker-compose` locally
- Build features locally
- Use a production tuned `docker-compose` yml file to build images locally
- Push the images to Google's Container Registry
- Then I run `eval $(docker-machine <name> env)` to tunnel into my production
- VM's docker
- Then I run `docker-compose -f production.yml pull --ignore-pull-failures` to
- download the new images
- Then I run `docker-compose -f production.yml up --no-deps -d` to restart my
containers with the new images
This process works great. I don't need to setup CI for a new project but it
still provides me with the flexibility to deploy to my own VM and inspect its
health with docker.
# The problem
Things are working great, I'm iterating on feature development and deploying in
between major changes. Only, the last deploy I tried to perform failed. The
reason: hard drive is out of space. Hmm, my VM has 16GB of diskspace, why is it
out of memory?
When I run `docker system df` the problem becomes clear: I have unused images
soaking up all of my hard drive space. I have scoured docker deployment
strategies and never came across documentation that references this issue. There
are plenty of StackOverflow issues referencing the problem with a solution, but
I never really made the connection to my production VM until I hit this problem.
# The solution
Before I pull my new images in production, I run another command:
docker system prune -f
=> https://docs.docker.com/engine/reference/commandline/system_prune documentation for system prune
Once I added that to my deployment step, things are working much more smoothly.
# Conclusion
I completely forgot that as I deployed new changes to production, there was
lingering old docker images laying dormant on my production VM, increasing in
size of time.
It never clicked for me until I ran into the problem, hopefully this short blog
article will help others avoid this problem in the future as well.
</content>
</entry>
<entry>
<id>gemini://erock.io/2014/07/14/heideggars-brilliance/</id>
<link href="gemini://erock.io/2014/07/14/heideggars-brilliance/" rel="alternate" />
<title>heideggars brilliance</title>
<updated>2014-07-14T00:00:00Z</updated>
<content>> Philosophers since Descartes had been trying to prove the existence of the
> external world, and Kant said it’s a scandal philosophers have not
> successfully proven the existence of the external world, and Heidegger said it
> was a scandal people are trying to prove the external world.
Rarely do I care to read the musings of a philosopher with more obscurity than
my girlfriend’s makeup routine, but I do enjoy Heidegger’s distilled brilliance.
Technology, something I think Heidegger denigrated vehemently for being
antithetical to Being, is ironically illuminating his ideas on Being.
After reading my own writings, I fear as I think Heidegger did, that language is
the core of obfuscating the meaning of being. We are bound by our rough modes of
communication, and it seems more common than not that it confuses what we mean.
I find Heidegger to be a stunning case of irony: his verbose writing style
describes precisely what he is ridiculing, the obfuscation of dasein.
</content>
</entry>
</feed>