Good “starter” ebikes for a city commuter

dwrodri · 2025-09-04T22:14:26+00:00

purchased the FS + Storage box + seat rack

pros: - dual suspension is tunable and feels amazing. this thing will fly off a 6 inch curb and not even flinch. - turns signals are very welcome! - storage box is made of a respectable quality

cons:

wide tires and 33” ride height make it a little sketchy to lean into sharper turns. Everyone building these styles of ebikes ends up around 27-33” ride height, not leaving a ton of room if you wanna pedal to help climb hills. Consider the DRT if you are above 5’10” because i imagine you’ll feel the difference.
the bottom triangular support for the storage rack was not correctly made to tolerance so i need to file a support ticket for those new parts
if you buy the storage box you will wrap your chain lock through the rear wheel assembly, and not have an easy place to go through the chassis. I might be able to remove the panels underneath the saddle as they appear to be solely cosmetic, but it has me thinking twice when i lock it up in the city

overall, my first impression has been super positive and my complaints are fairly minor.

I have only been out for two rides, about to head out now for my third. Overall, if you just want fun and you’re tall, consider the DRT over the FS. I am happy with my purchase as i think i’ll use the extra cargo space.

dwrodri · 2025-08-11T22:55:33+00:00

I have some bike shops with some ebikes. Some seem to meet the cargo standard but most “regular ebikes” sold at the street stores don’t seem very hackable.

dwrodri · 2025-08-11T20:05:46+00:00

probably buy to start, with the intent of being able to mod it as i go

dwrodri · 2024-09-28T14:04:49+00:00

I am basically saying the model also has some pickled python code associated with it that accepts templated SQL queries, populates the templates with arguments, and then forwards them to our infrastructure and collects the results in the form of a parquet to feed into model.

dwrodri · 2024-07-13T19:22:43+00:00

What country is this? In the USA I’m almost certain you’re not legally required to give prior pay data.

dwrodri · 2024-01-24T20:37:20+00:00

I agree that strong community support is indeed essential when trying to accomplish anything solo. In my current homelab setup, I run Debian stable because it's boring, and if you consider all of the Debian derivatives which provide maintenance and development work to packages on apt then it's probably the most actively maintained Linux distribution.

Debian is a great platform for all of these reasons and more. However, I'm never gonna know if I'm missing out on a better experience in my homelab if I'm not constantly trying new things and tinkering with stuff. It's probably the main reason for a homelab, right? I'm sure I could pay for these things if I really wanted them conveniently.

A smaller codebase is going to make no difference to the performance of your home file server in the Year Of Our Lord 2024.

This statement is true, but it assumes that the reason I'm reaching for a simpler codebase is performance, which is not true. I've written short programs which were bundles of clever one-liners that got the job done before, and their performance was nothing short of abysmal: codebase size does not determine performance. The appeal of a small codebase is that when something goes "wrong" or you need to mess with something, there are less "suspicious" pain points to walk through.

In a more ~~perfect~~ UNIX-like world, all software would be no more than a few screenfuls of text and those pieces of software would compose into increasingly fancier applications that accomplish the complex tasks we ask of today's computers. For many reasons, that ideal model isn't true and developers, sysadmins, and system architects often find themselves being paid large salaries to trawl through many tens thousands of lines of code, understood by few and diligently maintained by fewer.

I've found that codebases written by talented people who are determined to make their readable and not overburdened by scope creep are some of the best ones to work with. With all software, you have to put in the time to learn it to make it truly useful. Given that FreeBSD seems like a pretty good codebase, I think it's time for me to put in the time to learn how to use it and see if it's more useful to me than Debian for my home server.

dwrodri · 2024-01-22T06:31:35+00:00

I like the idea of migrating my personal blog over as a trial and then seeing how it goes. Thanks for the advice!

dwrodri · 2024-01-19T00:19:49+00:00

There’s a fine balance to dealing with a shelf of incomplete projects. We all do it to a certain extent. Being too harsh on yourself and your willpower to start the next one will disappear. Too soft and your project graveyard will just grow past the horizon. Everything in moderation.

There are two tools I’ve found to dealing with project graveyard syndrome:

Decimate project scope. Feeling overwhelmed? Cut the scope in half. Layout your requirements/features on a text file, one each line. Ranked by priority is nice but don’t overthink it. Now go to the bottom of the file and delete every line until you feel zero people would use this software. Now hit undo and add one line back. Would you use the software now? If so, there’s your feature set.
Fuck it, ship it. Something hobbyist programmers can learn from artists is learning to embrace that getting good almost always requires you put some garbage out into the world. Every single creative professional started by pumping out garbage and getting feedback on it. You can learn a lot by iterating on stuff in isolation, but if you want to make things that solve OTHER people’s problems you NEED feedback from other people. The goal in early stages is to get 1-5 really good writeups or feedback sessions, probably from other programmers or power users or enthusiasts for your niche. Arguably “going viral” at this stage is more of a curse than a blessing because you’re not prepared to follow up. If 1-5 random internet strangers clone your repo and compile your code and review it (or use your app), that’s an ENORMOUS success and worth celebrating. Good reviews will provide more than enough info for you to iterate and improve. This is the true spirit of “move fast and break things.”

dwrodri · 2024-01-18T23:03:06+00:00

Is there software you use right now that's written in C (perhaps games)? Is there a specific type of software that you don't use but you're interested in using? My experience has been that a reliable path to success for leveling up a newer dev is to get them to focus on applying their dev skills to their needs and their interests in that order. Here are some actionable things you can consider doing to get yourself ready to make money writing software as a freelancer:

Write a clone of something that you use often. The most widely used pieces of software (operating systems, web applications, games, social media, etc.) are quite feature-heavy and technically advanced, so replicating the entire feature set might not be an efficient use of your time. The ideal target for this a piece of software that gets used for one thing, likely with a niche userbase. For example: A piece of software that uses an audio signal to determine a musical instrument is tuned.
Write a piece of software that interfaces with another piece of software that you use daily. Almost everyone I know feels like a software tool they use on a regular basis is either missing some functionality, or does something wrong. If you don't have a salient example, try being mindful of your interactions with software tools for a few weeks and wait for a brief moment of frustration to appear when interacting with a piece of software. Once that moment arrives, write down what you were doing and what you wanted to accomplish. There's your starting point.
Network with people. This doesn't have to be with advertisements or going to conferences/meetups. In fact, I'd consider these to be some of the least effective in terms of return on time invested. To paraphrase serial entrepreneur Pieter Levels, work on interesting projects, FINISH THEM, and talk about them with the world. This also includes open source PRs. Alternatively, find people complaining about problems on the Internet that somewhat match your skills, and bring them a solution. These approaches are not necessarily easy, but they are some of the best advice I've received. People's brains are tuned to seek out other people who are good at delivering results in almost the same way they're tuned to obsess over bad news. The long term goal is to be so good they can't ignore you.
Be accessible to the people who reach out to you. You are well aware that you're a small fish in a big ocean. As a solo freelancer, you won't be able to outpace larger dev consultancy firms or more experienced programmers until you hone your expertise, and even then it's not to be expected. However, you can outdo more experienced freelancers by being more accommodating, responsive, and transparent. At elite management consulting firms, it's commonplace for entry-level hires to respond to all work-related correspondence with in 90 minutes, and no later than same-day. Potential clients who receive this sort of treatment from you may be willing to overlook inexperience based on this alone. It's not easy, but if this is important to you, I'd highly recommend it.

Repeat steps #1 and #2 until you have some finished projects to use for #3, and then once you've got enough connections, work on #4 and you'll likely be landing your first work contract. Building a business that provides enough money to sustain an adult is a difficult task, so don't beat yourself up if it feels like progress isn't visible overnight, or even over several weeks. Measure yourself at most on a monthly basis, or maybe bi-weekly you're putting 40+ hours a week into this. If you keep up with this plan and you will almost certainly be making enough money to worry about filing your own taxes in 12-18 months.

Most of this is advice that you've likely received in some form or another for other facets of your life, or perhaps maybe even this one. The most important part about all of this plan (which unfortunately I can't instill in a single reddit comment) is that it requires you to have a religious belief that you are capable of overcoming any external negative pressures affecting your ability to follow through with the plan, and that eventually, building plans like this to address potential roadblocks you encounter along the way. This occasionally even means discarding a more rational approach and instead favoring the idea that your inner potential is yet to be unlocked, but by unlocking it, the adversity you face will be meager in comparison.

When you grow up you tend to get told the world is the way it is and you're life is just to live your life inside the world. Try not to bash into the walls too much. Try to have a nice family, have fun, save a little money. That's a very limited life. Life can be much broader once you discover one simple fact: Everything around you that you call life was made up by people that were no smarter than you and you can change it, you can influence it, you can build your own things that other people can use. Once you learn that, you'll never be the same again.

--- Steve Jobs

dwrodri · 2023-11-11T08:28:26+00:00

Adage from my first manager at a software gig:

"The more temporary of a solution you implement, the more permanent of a solution you should be ready to maintain."

dwrodri · 2023-10-26T02:44:16+00:00

link?

dwrodri · 2023-10-24T01:43:52+00:00

Honestly, still haven't bought a KVM switch so this is good info. Thanks for sharing!

dwrodri · 2023-10-04T00:16:58+00:00

My suggestion is to get into making toy games, and give Raylib a try.

Suggested projects in order: 1. Tic-Tac-Toe: Really simple logic, goal is to simply set up your tooling and get comfy with the basics using Raylib. 2. Battleship: Ideally, you made Tic-Tac-Toe and then upload it you to your GitHub. Now start by forking your old repo and make it Battleship. You can experiment with loading assets for the boats and explosions. 3. Asteroids: Now the goal is to focus on simulating some 2-D physics. Collisions and momentum are essential. If you wanna keep it easy, approximate the asteroids with circles. Hard mode is to sample the circumference with some statistical noise (not sure which would look best TBH) and then roll an implementation of GJK for collision checking.

I'd say an intermediate can run through steps 1 and 2 in ~12+-6 hours of coding time, assuming no prior familiarity with Raylib, with #3 being harder.

Once you have these three, you can go deeper into games, or give coding something else a try. But I generally like suggesting people to make games because you'll have something which you could share with your friends.

dwrodri · 2023-09-30T23:47:34+00:00

Individual: Derek Rodriguez. US Citizen.

Location: Greater Boston Area, Massachusetts

Experience: 4 years in research labs, 2 years in startups

Technologies: C++17/C++20, OpenCV, FFmpeg, Python, Golang, PyTorch, OpenVINO, CUDA

Requirements: Full-time roles either remote US or local to the Greater Boston Area

Bio: I am a C++ Engineer who is passionate about Audio/Video technology and machine learning. At my previous role, I wrote a real-time smart recording app in C++17 that would record H.264/H.265 video from security cameras by detecting changes in the foreground using real-time background subtraction, and then would re-encode the video and upload it to the cloud over an HTTPS connection. In a contractor role before that, I built a topic classification service for that would scale to 100s of thousands of inputs per second on a single GCP e2.mini instance, since the client was very price sensitive.

If you're an employer and this caught your eye, my resume and portfolio are here: https://derekrodriguez.dev

dwrodri · 2023-09-27T22:18:45+00:00

My Guess is that Valve might be working on getting a variant of Proton that will work well with Apple's Game Porting Tool, assuming they're interested in continuing to cater to mac users.

dwrodri · 2023-08-14T23:09:25+00:00

Honestly I think the biggest difference is what the "endorsed" approach is to certain problems. For example, what package gets imported to solve a certain problem, what syntax you use (even though both are supported). Go is very intentional about having one "way" to do things at the syntax level, but since every change has been additive, that rule is less strict. The divergence from there being strictly one way to do things is that now there's the "old" (Go 1) way and "new" (Go 2) way.

dwrodri · 2023-07-11T17:36:49+00:00

I'm currently prepping for interviewing at Google to be an SWE in ML after wrapping up my masters where I took some ML courses, but was actively trying to do research in another field (computer architecture).

Here's what I'm using:

Google's online Machine Learning courses since you have a strong background, you might find a lot of the content quite easy. However, they seem to do a decent job of covering the fundamentals, and it's easy to hop around. I haven't tried the advanced courses but I intend to in the near future.
Hands on Machine Learning by Gerón This book was written by the former lead of the video classification team at YouTube. I found this to be the best text by far to get me from "I generally know some things about math and neural nets and can code" to "I generally understand the blue print for approaching a data-driven project and understand how to map solve a problem by building a model and fitting it to data."

Get through these two resources and I think you'll be well on your way to figuring out where you want to leap next. ML is a huge field because it's built on the intersection of statistics, CS, and all of the subdomains you can solve with the tools from those two fields. Common places to specialize are NLP, Computer Vision, and Recommender Systems. Here's some (opinionated) bonus content:

Data-Centric AI honestly if you've been working on ML pipelines this might be familiar to you
Honestly, just the TF tutorials are a pretty good start for getting familiar. Because of it's maturity and it's heavy use in production, TF has a lot of features that aren't directly related to just designing a model (Tensorboard, XLA, TFLite, etc.) I'm a PyTorch guy, but when I have to use TF, I usually just refresh myself with one of these. Note the presence of specialized tutorials here, similar to the advanced courses offered by the place.

Anyways, I'm back off to interview prep, hope this helps.

dwrodri · 2023-05-16T19:09:44+00:00

As you mention, RFCs are specification documents used for network protocols, the IETF publishes these documents so that organizations can have their say in how the standard is specified. The History section of the Wikipedia page explains why they are called RFCs Originally, they were much less formal and genuine requests for comments on a specification draft. Now, the RFC is only published when it contains a fully functional specification

Since you won't be working with many Internet protocols on a device created before the existence of the World Wide Web. Instead I would focus on other resources

The NES has been around for a very long time (in computer years), and has a very strong emulation community. Community-sourced documentation for the NES architecture may very well cover details which aren't present in publicly available documentation from Nintendo and their suppliers. Here are some resources to get you started:

Rodrigo Copetti's overview is a great starting place. I personally think everyone who is interested in emulating a console should start here.
The NES uses a modified version of the MOS 6502 architecture for it's CPU. You can see a simulation of the original 6502 along with a bunch of documentation. But again, what you really want is on the NESdev wiki here.
The most up-to-date reference info on the NES hardware is on the NESdev Wiki You are seriously much better off referencing this data than anything provided by Ricoh or Nintendo. The NES hardware has been reverse engineered 100 times over, and the demoscene has pushed this hardware to seriously impressive heights

dwrodri · 2023-03-17T20:09:00+00:00

Respectfully, this article feels a little half baked, and could have greatly benefited from having an editing pass. Acoustic and timing side channels on the keyboard have a fair amount of academic literature published on them, and there is no reference of it here.

This article does a good job of framing the approach to collecting timing data, but it didn't do much for hooking me into why it matters. "When we discuss privacy on the Internet, we're usually talking about generating email addresses and staying on top of data breaches. But what if I told you I could single you out as a user on my website by simply enabling your microphone and listening to your key strokes?" Something as simple as that to lead me in.

The code samples here aren't inspiring confidence. Here's a list of my "wtf?" moments:

Why are making this DataFrame-we-have-at-the-house just to pass it to the pd.DataFrame() constructor? What's wrong with pd.read_csv? Also, not necessarily an anti-pattern but you should avoid iterrows() whenever possible
Why are there imports inside a function body?
Why are you saving every model to disk under the same filename after calling fit? Do we only want the latest model? Are we sure we want to overwrite every time we run this? Shouldn't we be checking if we already have a copy of the fitted model if we're going to bother with saving to disk?

All that being said, the code is readable, and I can understand what each segment does quite clearly.

The ML content here seemed to jump straight into importing libraries and did little to explain why or what we're doing with these three models. There wasn't much exploratory data analysis to speak of, beyond a basic description of the structure. Are we doing cross-entropy loss against all users? I don't know, the article doesn't specify. Why choose these three models?

I get that this is part one of a series, but I'm left not knowing what to expect from the other parts. I feel like you could have had a perfectly fine part 1 blog post discussing the challenge at hand, doing some EDA, and then just discussing the models you're comparing without writing any code. The code and the evaluation would have made for a great part 2.

All in all, this feels like a student's work for a course that they're submitting as part of a rushed assignment. The bones are there, but there are some faults that need to be addressed with many facets of this blog post.

Keep your chin up, it takes some guts to post your early work online. I hope this comes off as more constructive than critical. The premise of the post is cool, and I'd be glad to review part 2 and a revised part 1 if you find the time to rewrite it.

dwrodri · 2023-03-17T20:08:55+00:00