conradk

What I mean is that compared to testing in browser, writing unit tests and using those tests instead of the browser takes about the same amount of time. So doing tests in browser or in TDD ends up taking the same amount of time upfront. So testing in browser is as expensive as writing unit tests with TDD.

You have to write 10 of them if they are not part of your workflow. If you TDD (which is applicable in a lot of cases in my experience with web development), then instead of testing with Curl or a web browser, you write tests. This takes the same amount of time upfront, so the additional cost of writing the tests is actually 0.

Not sure about other types of development, but in web development, TDD can be a good way to have automated tests without the additional cost.

I've seen master-replica being used a lot too

When I see something like this, I immediately think: what's the difference with Piwik / Matomo ? https://matomo.org/

Totally! Forks can be great.

Saying "Caddy was supposed to be great" or "This is no longer just a conversation on privacy; this is a hostage situation" is not right. Caddy is great, but Neflabs doesn't agree with the direction it's taking. The solution is not describing the free software's developer as a hostage taker.

The solution, as you said, is forking.

It's amazing the lack of gratefulness some people have for open source devs. Matt Holt, which I don't know nor have ever met, has spend a tremendous amount of time developing Caddy and making it available for free. It's creating a lot of value, regardless of what you think of recent telemetry announcements.

And still, apparently, some people will use the slightest disagreement to say that the whole project is garbage, just like this article is doing. I think we're lucky that open source developers don't get deterred by these kinds of article, because they sure could be. What does religion have to do with the quality of a free software project ? Does your server run better if coded by an atheist ?

Instead of being disdainful, a more constructive thing to do would be to openly talk about forking, on Caddy's forum, and see the response. If nothing changes, fork and convince people that your fork is better.

I was just thinking about this. Ideally, the median and mean salaries should account for added value but not vary so much as to make inequality unbearable. Having CEOs paid 100 or 200 or even 1000 times more than other employees is bad for everyone in the long run. It leads to so much inequality that people end up tearing each other appart, looking for culprits (immigrants, strangers, neighbouring countries, etc). Having a CEO paid more than others is fine as long as everyone can benefit from the added value, not just a few.

That would be great indeed!

I think the problem here is that this is a Gmail-specific, non-standard feature, meaning there is no specification that allows to implement this in a reliable, cross-client way.

However, Fastmail is working on something similar with JMAP.

I found this earlier HN comment to be really interesting: https://news.ycombinator.com/item?id=16372835

It's amazing that in 2018 we keep building new CMSs. Human curiosity is without limits. I'm genuinely amazed about this. And seeing a CMS built with Go is refreshing.

I have to say though, the "What doesn't it do?" section seems like an extension of the "What does it do?" section. A "What doesn't it do?" should list what the CMS actually doesn't do instead of listing things nobody wants anyway. Who wants "hundreds of complicated back-end screens"? No-one. So no need to say that the CMS doesn't do that.

If we had to stop doing something every single time someone thought the world didn't need it, we wouldn't be doing much.

Adding "ignore-scripts=true" to your ~/.npmrc helps here.

Frexit seems to be coming ever closer. Le Pen got 35% in 2017, pro-frexit parties are flourishing in France. EU has got to be careful. It's doing good things (free roaming, which as citizen who has family in both France and Germany, I highly appreciate) and the GDPR, which seems to force companies to think more about privacy.

But if Github's phrasing accurately represents what EU wants to do with online sharing, then I feel like this change is a step in the wrong direction, restricting privacy to make big-corps even richer than they already are.

> Much faster than running the same tests on my local machine as well.

That sounds odd. Usually, while developing, running the whole test suite is unnecessary. So running tests is very fast, as long as you only run the tests that may fail after recent changes. At least that's my experience.

> not need to commit such large amounts of data that it becomes a problem

Not sure what you mean here. Mind clarifying ?

> if you are working remote it's expected that you have a stable, decent, connection

Definitely ! And 90% of the time I do have a stable connection. But that 10% where I don't (because the wifi breaks down, or I'm on a train to a nearby town), having a remote environment would not work. That's my use case for having a local environment.

> For documentation I actually keep that local using https://devdocs.io/.

Wow, that's cool ! I wasn't aware it worked offline ! Will definitely have a look at this. Thanks :)

Well, with web IDEs, the server is remote, isn't it ? The reason here was the same: easy to setup environment because every dev had the same server image, with same config, etc. I guess that's what remote IDEs have going for them. I think Koding.com markets this very very well.

Coding without any kind of test and getting it right sounds incredibly difficult to me. How do you achieve that ? What kind of code do you work on ?

I wasn't using a web IDE, but the dev server was remote. While I suppose remote environments do not have to be a huge pain, I'd be interested to know how to mitigate all of the issues I mentioned in my previous comment. The only solution I've been able to setup is a local environment with minimal set of dependencies calling the network.

Recently, I've experienced working on a remote server. It was a real pain. You need a crazy fast connection to be productive. Otherwise, you're stuck waiting for changes to save, for pages to load, etc. Of course, you can only hope the network doesn't break down or the cloud IDE company makes a buggy deploy.

As a remote developer, I like working in different places. These places don't always have nice internet. Working with a local environment and 4g connection is fine, because 4g is more than enough to look up docs. But working with a distant environment and 4g connection is very slow and unreliable.

Nowadays, a lot of people praise the "cloud" or everything. Use APIs for everything, Use public CDNs to load up bootstrap and jquery. Use an online IDE. Make a hosted Git service an essential part of your workflow. The thing is, not only do these services occassionally break, but some might get compromised (https://techcrunch.com/2018/02/12/browsealoud-coinhive-moner...) and some even ask you to install closed source binaries to your system without any idea of what's in it (keylogger, ransomware, anything is possible).

Given all that, when I read that using a local environment is "anachronistic", I can't help but cringe.

Hence tools like Zappier. I've had great success getting all notifications in Slack via Zappier, reducing switching between different tools. But that means that Zappier has access to EVERYTHING, which somewhat scares me from a privacy and intellectual property standpoint.

I use i3wm and always feel left out of these kinds of tips, because i3wm uses Alt for all kinds of Window Management stuff. If I do Alt-F, my shell goes fullscreen, because i3wm is setup to do that.

Any tips for i3wm users that have these kinds of keybind conflicts ?

That's interesting ! Will try that sometime. One question though: how do you deal with mutating methods? Like methods that would persist a value to storage and only should do so once?

I've found GNU macchanger to be the easiest way to do that kind of stuff. It's as simple as:

macchanger -r <interface>

Interesting article about macchanger on the Arch Wiki: https://wiki.archlinux.org/index.php/MAC_address_spoofing

Clicked through the link to the security apps on the Github Marketplace and had a look at Snyk.io's pricing: 119$ through Github, 99$ if you get it straight from Snyk.io.

And looking deeper into Github Marketplace pricing, I can see that Github takes a 25% cut (https://developer.github.com/apps/adding-integrations/managi...).

What is the benefit of getting anything via the Github marketplace that can be subscribed to outside of the marketplace ? What justifies that 25% cut appart from having a listing of apps ?

I really dislike it when companies use a new extension like "github.community" instead of a subdomain like "community.github.com" because there is no real way to know if the site is a phishing attempt or not. Getting people used to accept going to another site seems very bad for security. Especially when there are already domains like http://github.co (notice the .CO instead of .COM) that don't belong to the trademark owner.

It was renamed to faircode.io

Saving a webpage to a PDF is literally one command line away:

chromium --headless --disable-gpu --print-to-pdf=google.pdf http://google.com/

What does Apify add in this case?

I'd say "There's Slack's problem". Having different emails and password to each and every Slack account you have is tedious to work with. Would be cool to have a single account to manage all workspaces. Kind of like you can join multiple repos as a collaborator on Github with your personal account.

Seems like a very complicated business to get into compared to chauffeurs, no? In Paris, Uber doesn't seem to handle cars at all. The drivers buy/rent cars from wherever and drive. And drivers are in charge of their car's maintenance, repairs, etc. Uber provides the smartphone apps and underlying platform. That's a challenge in and of itself, but not at the same challenge as maintaining thousands of vehicles I would bet.

You are being subjective here. Maybe you like driving for more and cheaper products, but not everyone is like you: not everyone drives, not everyones wants to drive, some people prefer supporting small shops than big ones, etc, etc.

There is also a problem of large companies making it seem like they don't make money, through complex financial montages, when in fact they do.

I disagree that as web engineers, our goal is to make websites faster. Our goal is to make a website that suits the customer's needs.

Sometimes, that can even mean making a website slower. I've had that request before because end users were surprised that the site loaded so fast. We made stuff slow on purpose so that the user thinks we are crunching data hardcore and giving their request some real thought before presenting the results.

Sure, if the customer asks for ultimate speed and explicitly does not care about image metadata availability, then removing that metadata is fine. But otherwise, removing those few bytes probably won't change how fast your website loads by a significant amount. You're better off working on caching, reducing TTFB, automatically adapting image size to screen size, spriting icons with http1, server push with http2, gzipping, reducing the size of Javascript/CSS and working on perceived speed. This will probably be orders of magnitude more useful to users than removing image metadata. And it won't remove that useful information from images.