rtomayko

Interesting to see this as I’ve never heard returning to adolescent interests being common but that’s exactly the path I followed after leaving tech. I tried getting into sound engineering because I loved recording with rented 4 track recorders and early software DAWs in my late teen years. It didn’t stick and I ended up going back further to when I found an old Honda Trail 70 in a barn when I was a kid and rode around absolutely everywhere in my local area just to explore.

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.

This is specifically allowed in the Linux kernel coding style guidelines as well FWIW:

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

I made the jump to a System76 Adder WS laptop and pop!os for development after buying the lemon first gen MBP with the terrible keyboard. It was my seventh and possibly last MBP (including powerbooks before it).

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.

It definitely was:

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

(Related)

I’ve seen this referred to as “satisfying your inner Linnaeus“ and have spent way too much time in that weird place myself.

I’ve been thinking about bike vs scooter a lot lately too. Austin is overrun with scooters and I used them for a little while before finding the electric Uber Jump bikes. They seem superior to scooters in every way in Austin, which makes the 20:1 ratio of scooters to bikes a bit baffling.

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 used a chemex + quality grinder for a long time and haven’t found anything better so not much to add there.

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.

https://auth0.com

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

I've always loved this idea.

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.

I'm as keen to see memory safe systems languages become commonplace as anyone but some 90% of our stack is C - Linux, MySQL, Git, MRI, nginx, haproxy, memcached, redis, and many other internal components that we'll be talking about on the engineering blog soon. We like C. We're going to need a few more years of research, real production experience, and language/library maturity before betting critical infrastructure on something else by default.

"Unfortunately, your request for a 5% raise was rejected. We're sorry to see you go. Can you help hire a replacement? Just write up a quick job posting w/ your basic work experience and daily routine. Thanks."

We thought the Downloads feature was doing more harm than good in its previous form. Quality-wise it just wasn't up to snuff (failed frequently, flash, lack of design). Bad experiences on the site need to be fixed or killed. No one was willing to dedicate time to fixing it because they felt their time was better spent on other things so that left killing it.

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 don't talk about unshipped features as a rule. It's hard to do so in a way that doesn't imply promises or timeframes.

Ouch. Sorry about that. Opening an issue now.

I'm looking into why those are showing up in the issues list. Likely a bug. The user has been marked as spammy for over a month, though, which means notifications (email or web) are not delivered.

We should have this cleaned up shortly.

Your commits will count for the day they were committed once they're merged to master. i.e., It's the date on the commit that matters, not the date it's eventually pushed to master. A little weird since it means past days can fill in later but we wanted to make sure they were counted.

These buttons are only displayed for users who have installed those tools. We're not using it as advertisement, we're making it convenient for people who have already installed the tool.

We actually don't care about rate limits with this type of raw request. The limits are in place because people (usually porn sites) hot link js/css/image assets which can lead quickly to an insane number of requests.

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.

I couldn't agree more. There are also many practical issues that I rarely see touched on in these yay SOA articles, like:

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.

No. There's simple conventions for adding feature flags (user.some_feature_enabled?). Features are enabled and disabled by changing the code and deploying. This works because deploying new code is fast.

Wow, really? Really sorry to hear that.

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

I'm a developer at GitHub.

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.)

Yeah. I mean 4,517 seems like a big number to humans but meh. You're talking about a highly optimized parser. It's likely going to rip through those quotes in about the same time it takes to dispatch a single unjit'd/unoptimized javascript function invocation at runtime.

Do you use parenthesis to denote order of operations in all cases, even when extremely obvious? If not, should we assume your position is absurdly immature hipster posturing that serves no engineering purpose?

I'd agree with you if not for the many subtle and critical bugs I've seen introduced into our production environment due to and/or precedence problems. The increased expressiveness when used correctly is just not worth it.

Do you use semicolons in Ruby, Python, shell, or other semicolon-less language where semicolons are allowed? If not, what's your justification for omitting them?

Assuming your main product is on the web, you really only need a few things to do this right:

- 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 exactly why Hubot was created in the first place. An excerpt from the original project README:

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.

(I work at GitHub.)

Linus wrote into github support with some good and pointed feedback as well, most of which was related to email sent when a pull request is opened vs. what you might expect to see when someone submits a patch series to a mailing list. I assume this is what he's referring to with, "so from the pull request it's actually hard to see what somebody asks you to pull," in the quoted bit from the article. We have some changes lined up that we hope will address this.

As for the quality of pull requests, it's unfortunate that a people took this as an opportunity to troll (https://github.com/torvalds/linux/pull/6). That will hopefully settle down once this is no longer "news". If not, we'll find a way to a address it.

Lastly, it's worth noting that the linux-kernel mailing list -- where the majority of linux related development and discussion happens -- is an open list (i.e. doesn't require subscribing / passing moderation to post). The ability for anyone to send a pull request to anyone at any time on GitHub is based somewhat on the success of open-list policies on projects like the kernel. While we're always looking for ways to help with trolls, the basic model isn't something we think needs to be "fixed".

I don't think we have any strict non-drinkers but there's definitely some lightweights (cough Holman cough) so I think he'd be fine. ;)