Recent submissions

Comment · 6 years ago
Imho the "otherwise" option should be on the top of your list.

Tools/best practices come and go, can be learned quickly with so much information out there.

That said, be curious and try different things and you will know what you like. Passion amplifies learning by a magnitude.

All of the above is imho, that I would've told younger myself.

Comment · 6 years ago
The problems I see with "open your browser" for quick testing: 1. it's short gain, the team will be slower (will they know how to test it?) 2. how much code needs to be written so that you can even use the browser to test it?
Comment · 6 years ago
It's a trade off. Sure, the ultimate testing is done by customers, but how fast one can push new fixes without tests? 1 reported bug could break many things.
Comment · 6 years ago
Comment · 6 years ago
Imagine assembling a car engine without any QC process, perhaps just visual inspection of the parts. The end users (whoever will drive the car) will be the actual testers.
Comment · 6 years ago
I couldn't tell if this is a joke or for real.

My 2 cents regarding testing. Written tests have 2 goals, 1: help to build your code (you verify your code as you write it). 2: Regression testing (new changes have less chances to break your code).

We as devs need to hand over/deploy a verified code. Without tests this means manual testing, without manual testing means not verified code. Manual testing means slow development process.

It's 2020, I think we have more time writing tests than before with all those cool IDEs, tools, frameworks. No tests means laziness and/or cockiness. Imho of course.

Comment · 6 years ago
Personally I will believe it when I see it, at least for Pro line. Apple has the resources to pull it off (although they will be remembered by their keyboard issues for some time), the question is what is Apple's ultimate goal?
Comment · 6 years ago
> ... what I write is useful just as a side effect, but my first goal is to make something that is, in some way, beautiful ...

I love beautiful code too, however if it's not useful, then the beauty fades quickly for me. What's the point?

Comment · 6 years ago
Google is grooming next generation of users. It wants to be the Internet, the way IE (the E logo) used to be Internet to many users.

Can you imagine removing house numbers from Street addresses? "Where did you buy that? On Main Str., but there wasn't any number..."

If the URLs are ugly it's not Google's place to regulate that, but website's owner.

If this is to protect users, then instead of removing information, add and/or make it more user friendly.

Comment · 6 years ago
I don't know, I guess it depends. I tried recently to switch to gruvbox dark, solarized dark and so other popular themes. It is difficult for me to use them in the day. Gave up after couple of days, switched back to intellij light + redshift app.

Late nights i just reduce the overall screen brightness.

Comment · 6 years ago
Indeed, team's experience is not relevant in the definition, however it's the main criteria to choose a [boring] tech, after the cost of course.

To use/apply any tech or workflow depends on execution.

Comment · 6 years ago
Boring tech is subjective, it depends on the team. A tool for the job needs to be in right hands to be right. Some may be fine with 1 hour after hours deployment, some may want a fully automated CD pipeline.
Comment · 6 years ago
It doesn't specify who serves it at that speed either, could be some kind of "serving machine".
Comment · 6 years ago
Thank you for your input, that's exactly what I meant.
Comment · 6 years ago
Thank you.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton