rtomayko

I recently found the adventure riding community and built up a Husky 701 for multi-day (hopefully multi-week in the future) on/off road trips. It’s not unlike a small open source project but more physically active. I’m early 40s now and plan to explore on a bike into my 60s.

I also recently bought a ranch in Colorado. This isn’t from my childhood but turned out to hit all the right notes for me. Ranchin’ is almost impossible to make a profit at but I’ve met a bunch of people now who can’t stop doing it and I understand why. It’s a never ending stream of natural projects, big and small, that engage every part of you mentally and physically. Again here, not unlike a (larger) software project.

I went into tech because I thought I liked hacking, turns out I just like work, especially on systems you can iterate on every day and see improvement.

As for tech, I haven’t written a line of code in years and rarely use the internet except for practical things like maps and basic information. I still browse HN occasionally. Not sure why as there’s not a lot of content relevant to my current interests. It still has a little of whatever I loved about tech in the 2000-2015 era, which seems entirely gone from the wider internet now.

https://www.kernel.org/doc/html/v4.10/process/coding-style.h...

I was considering one of the new 13” MBPs but that seems unlikely if injecting network latency into syscalls is the direction things are going.

If you’re not building Mac/iOS apps, find a Linux laptop you can tolerate for development and an iPad Pro for everything else.

https://web.archive.org/web/20140416021831/http://lists.cano...

(Related)

But I can see your point in SF where I use to walk 5 blocks from my apartment to the muni train and then another five blocks from the train to the office. Scooters would have been ideal there.

The e-bikes have one massive advantage in Austin - you can take them on the Butler Trail that runs the width of the Austin along the river. You can get almost anywhere of interest very quickly on one of the jump bikes.

There’s also no useful bus or train transport in Austin (I thought SF was bad) so you’re not using the small transport to move small distances between larger transport as often.

I’ve started experimenting with roasting at home, though, and am surprised at how easy it is. Time since roast seems to be one of the most important variables for taste and beans are by far the largest expense. You can buy a 3lb bag of unroasted green coffee on Amazon for $20:

https://www.amazon.com/dp/B014THN4OI/ref=cm_sw_r_cp_api_L1Rl...

It takes about 13 minutes to roast a hopper’s worth of beans. I use a normal castiron skillet over medium heat. Just keep the beans moving the whole time.

I've just started dabbling on a small project and would be interested to understand how features overlap and differences in license/distribution model.

Fun fact: a blame-based suggested reviewers UI was included in the original Pull Request design mockups. We shipped with a much weaker list of everyone with write access list and eventually dropped the list altogether due to it not being very useful. I've always wished we would have revisited the blame based approach instead. A seemingly small feature that could dramatically improve communication and reduce noise.

The timing of the Releases feature only entered into the decision a little bit. It's hard to tell when something is going to ship at GitHub because there's no deadlines. Projects are done when they're done. The downside to this approach is that you can't rely on ship dates when making decisions like when to kill a feature something might replace.

We should have this cleaned up shortly.

If file extensions could be used to determine whether a resource could be used like this, we'd only apply the rate limits to those. Browsers don't care about extensions or event content types though. They'll happily use whatever's at the other end of a URL for <link rel=stylesheet>, <script>, and <img> tags.

As for whitelisting, it's a path we just don't want to go down for raw requests. We do a lot of that for the API and it isn't cheap to maintain.

Scaling down for development. If you need to start N separate services and work in three projects to get work done, things get tedious fast. Also diffs start to cross projects if you split things too granularly.

Monitoring and management in production. Every process is a liability and requires work to monitor and manage. A single set of homogenous processes is much easier to deal with than many sets of different types of processes.

There's a line where you can be too monolithic. There's also many cases where breaking out services is necessary for isolation and distribution - actual architectural properties that are useful. But I don't get this tendency to break things down for the sake of breaking them down. It seems to come from a very high level architectural view of the problem domain with little concern for practical issues in developing, deploying, monitoring, and managing systems over time.

Moving through trees is one of the fastest page level operations on the site as far as perceived performance. We'd like to make it faster but it's definitely in the area of perceived performance we're shooting for with the entire rest of the site.

Is there maybe something I'm missing here? What browser do you use? Are you primarily slowed down on the first request or when browsing layers deep.

Also, we wrote up the details on how we optimized tree browsing a while ago. Might be interesting from a general frontend perf perspective:

https://github.com/blog/760-the-tree-slider

This is a really good writeup and touches on many of the frontend issues we've had our eye on for a while. In fact, the <script> related bits are already dated. We've just rolled out defer support for these for instance.

I really liked the wrap up section on choosing which aspects of performance to concentrate on and can maybe answer some questions here:

> Yet, I am wondering what would be the performance business > case for GitHub? Even if GitHub does not feel slow, faster > is always better.

We want GitHub to be insanely fast and are pouring a significant amount of time and energy into this. We think it's more important than a lot of feature-type additions we also have planned.

(I also left a similar comment on JP's blog that's waiting for moderation.)

- Automated tests that run on push to any branch.

- Rolling deploys (no downtime) from any branch.

- Exception reporting system (Exceptional, Hoptoad, homegrown, whatever).

- Twitter search feed.

Push to a topic branch, wait for the tests to come in green, deploy from topic branch, watch exception notification and twitter. If everything looks okay after 10 minutes, push to master. If exceptions or twitter blows up, redeploy master.

You should be able to setup the whole system in about the same time as it takes to develop a majorish product feature.

This is Hubot, a Campfire chat bot in node.js.

The goal is to make common systems stuff seem less like black magic by turning frequently performed manual processes into simple commands and making those interactions visible to the team via Campfire. Benefits:

• Fast access to server logs and machine information when something goes wrong.

• Everyone sees how common tasks are performed.

• Interactions are logged and available in campfire transcripts.

• Let's us do stuff from the phone with Ember when AFK.

• Can paste squirrel pics and stuff like that.

For new people starting at GitHub, they can kind of just lurk in the chat room for a couple days to get a feel for how most types of things are done because people are issuing Hubot commands all the time.

It's really powerful. Way more powerful than we suspected.

EDIT: Formatting.