gregmac

no profile record

Submissions

8chan goes dark after hardware provider discontinues service

910 pointsby gregmac7 年前1,566 comments

comments

7 個月前discuss

> To put a bit more colour on this, I think the fear of most devs with an ultra-simple framework like this is that eventually you hit a wall where you need it to do something it doesn't natively do, and because the only thing you know is these magical declarative hx-whatever attributes, there's no way forward.

I'm not sure "fear" is exactly the right word here, but it's something I consciously evaluate for when looking at any new framework or library. Anything that has a lot of "magic" or "by-convention" type config is subject to this.

You start with the "hello world" example, and then you hit that wall. The test of an awesome framework vs a fundamentally limited (or even broken) one is: can you build on what you have with extensions, or do you have to rewrite everything you did? There's a lot of these where as soon as you want to do something slightly custom, you can't use _any_ of the magic and have to redo everything in a different way.

This isn't just libraries either. Another almost worse example is AWS Elastic Beanstalk. Simple way to get an app up and going, and it handles a lot of the boilerplate stuff for you. The problem is as soon as you want to extend it slightly, like have another custom load balancer route, you actually have to completely abandon the entire thing and do _everything_ yourself.

This is a really hard thing to get right, but in my view is one of the things that contributes to a framework's longevity. If you hit that wall and can't get past it, the next project you do will be in something else. Once enough people start posting about their experiences hitting the wall, other people won't even pick it up and the framework dwindles to a niche audience or dies completely.

8 個月前discuss

> if your source code is based on newer .NET you have to update to a new version each year

.NET has a really refreshingly sane release life cycle, similar to nodejs:

- There's a new major release every year (in November)

- Even numbers are LTS releases, and get 3 years of support/patches

- Odd numbers get 18 months of support/patches

This means if you target LTS, you have 2 years of support before the next LTS, and a full year overlap where both are supported. If you upgrade every release, you have at least 6 months of overlap

There's very few breaking changes between releases anyway, and it's often in infrastructure stuff (config, startup, project structure) as opposed to actual application code.

8 個月前discuss

It's good to move to Zigbee/thread/z-wave anyway because they're all better protocols for smarthome stuff. Plus wifi means you might be buying stuff that relies on cloud, which is a non-starter for anyone that doesn't like buying future paperweights.

But your criticisms are strange. You have more than 254 devices connecting (which implies a complex setup) but can't increase the subnet size? Or does your router just have an absurdly small default DHCP range?

I also don't understand the swap your router problem, unless you're also using default SSIDs and not changing it. Configure the SSID and PSK to be the same as before and everything will just work.

8 個月前discuss

> there’s not good support for very low power devices that use WiFi

That's why we have Thread. Wifi just isn't a very efficient protocol for using with deep sleep. The radio takes more power to run, the overhead of connecting is higher, and the device needs a full IP stack. Even with power save mode (if supported by client and AP), the radio is on for hundreds of milliseconds to send a message.

Thread has "sleepy end device" profile built-in where the hub will queue messages and expects the device to be in deep sleep most of the time. And since it doesn't have so much overhead, the radio only has to be on for tens of milliseconds.

8 個月前discuss

When I first saw the iPhone I remember thinking how silly it was that a device calling itself a "phone" only had the phone function as of many apps. Other phones had internet and other features, sure, but their "home" screen, so to speak, was a phone UI. You had to hit "Menu" or something else to see the other apps, which were clearly secondary to the primary phone function.

The iPhone felt more like a general portable computing device that happened to also function as a phone.

Even the Blackberry up to that point still felt more like an "email/phone device" primarily (though funny enough, I never had a Blackberry myself until after the iPhone came out).

The irony now, and I suspect many people are like this, is my "phone" is barely ever used as an actual phone. It's a computer with a data plan. I am way more likely to use some kind of internet-based voice/video chat than make or take a phone call.

My phone icon is still on my home screen, but only because it is something I want to be able to get at quickly in an emergency. I'm certain it's the least-used icon on the screen, though.

10 個月前discuss

It sounds like you think I'm victim-blaming here and that's not my intent at all.

Part of being in business is anticipating risks and having a plan -- which could be deciding to accept the risk. What sucks is you're implicitly accepting the risk of anything you didn't think of, even if the seller is quite aware or even counting on it. It's a harsh lesson when something this happens.

Slack are leveraging their position and it makes them assholes (or capitalists, I suppose, depending on your point of view), but you can't control what they do. You can only control your choices.

10 個月前discuss

> refuse to let them export it

Honestly, it's hard to feel too bad for people making the choices to use this stuff without considering an escape plan or safety net and then getting burned by it.

You choose to not get fire insurance on your house, your house burned down... like yeah, that sucks, I do genuinely feel bad that happened to you. But also, you took a risk presumably to save money and it bit you in the ass, and now you unfortunately have to pay the price.

Sometimes SaaS really does make the most sense. Having your people doing part-time, non-core operations of an important service they are not experts in can be a huge distraction (and this is a hard thing for us tech people to admit!).

But you need to go into SaaS thinking about how you'd get out: maybe that's data export, maybe it's solid contracts. If they don't offer this or you can't afford it... well, don't use it. Or take the risk and just pray your house doesn't burn down.

> It's so shitty and slow because it's a bloatware

Bloatware is unwanted software, usually pre-installed or otherwise not installed by the user, that slows down your computer and takes up space.

So if a user wants Office, it is, by definition, not bloatware.

Even if we do consider it bloatware -- pre-installed, unwanted by the user, and using up system resources -- that isn't an explanation of why Office itself is slow.

2 年前discuss

Yeah, IConfigurationService implies separation of concern. Code using it doesn't have to care where the configuration came from, just that it is there. Someone separately can write the concrete ConfigurationFileService:IConfigurationService that reads/parses files.

IConfigurationFileService implies abstraction of file system-based configuration. Are we planning that there's going to be a different way to read configuration files in the future, and what exactly is that? If no one can articulate it, it just seems like architecture astronautism and: YAGNI.

IConfigurationService makes writing unit tests for anything that uses it way easier, too. There can be a simple TestConfigurationService:IConfigurationService that just implements everything as settable, and in your test code you can provide exactly the properties you need (and nothing more), and easily have 100 variations of configs to ensure your code is working. Without the headache of dealing with actual files separate from your test code, or worse, shared with other test code.

I've actually written multiple long-lived pieces of software this way, and more than once ended up implementing stuff like environment variable-based configuration, REST API-sourced configuration, and even aggregations that combine multiple sources, eg:

    new AggregateConfig(new ServerConfig("https://whatever"), new EnvironmentConfig(), new FileConfig("/some/path.config"));

All that code that used IConfigurationService is completely untouched and unaware of any of this, letting whoever is doing this as part of changing deployment (or whatever) be productive quickly with very little knowledge of the rest of the (possibly massive) app.

3 年前discuss

> Because there's very little effort required to flag articles for deletion, and the burden to keep is often on the contributors doing research on a 7-day timeframe if there are even just one or two editors supporting deletion, most times the contributors eventually give up running the research treadmill and the content gets deleted anyway.

Pretty much sums up the problem with every community-run moderated site. It directly leads to the downfall because contributors get discouraged and leave, and eventually all that's left is people with the same view as the heavy-handed moderators. Having hours of work wiped out from editors/moderators who've spent less than a minute on it sucks.

Stackoverflow is another notable example of this.

4 年前discuss

Does anyone know of (or work on) an app still doing user-agent sniffing to determine browser features (as in, the sniffing code has been touched in the last ~decade)? If so, why do it that way?

4 年前discuss

Suddenly there's going to be a lot of spammers "running for office"...

4 年前discuss

The author defines two types of TDD: "weak TDD" and "strong TDD". I'd argue there's another, though I'm not sure what to call it -- "Pragmatic TDD" perhaps? What I care about is having unit tests that cover the complicated situations that cause bugs. I think one of the main problems with TDD is its proponents focus so much on the process as opposed to the end result.

The way I practice "pragmatic TDD" is to construct my code in a way that allows it to be tested. I use dependency injection. I prefer small, static methods when possible. I try not to add interfaces unless actually needed, and I also try to avoid requiring mocks in my unit tests (because I find those tests harder to write, understand, and maintain).

Notably: I explicitly don't test "glue code". This includes stuff in startup -- initializing DI and wiring up config -- and things like MVC controllers. That code just doesn't have the cost-benefit to writing tests: it's often insanely difficult to test (requiring lots of mocks or way over-complicated design) and it's obvious when broken as the app just won't work at all. Integration or UI automation tests are a better way to check this if you want to automate it.

I strive to just test algorithm code. Stuff with math, if/else logic, and parsing. I typically write the code and tests in parallel. Sometimes I start writing what I think is a simple glue method before realizing it has logic, so I'll refactor it to be easy to test: move the logic out to its own method, make it static with a couple extra parameters (rather than accessing instance properties), move it to its own class, etc.

Sometimes I write tests first, sometimes last, but most often I write a few lines of code before I write the first tests. As I continue writing the code I think up a new edge case and go add it as a test, and then usually that triggers me to think of a dozen more variations which I add even if I don't implement them immediately. I try not to have broken commits though, so I'll sometimes comment out the broken ones with a `TODO`, or interactive rebase my branch and squash some stuff together. By the time anyone sees my PR everything is passing.

I think the important thing is: if you look at my PR you can't tell what TDD method I used. All you see is I have a bunch of code that is (hopefully) easy to understand and has a lot of unit tests. If you want to argue some (non-tested) code I added should have tests, I'm happy to discuss and/or add tests, but your argument had better be stronger than "to get our code coverage metric higher".

Whether I did "strong red-green-refactor TDD" or "weak TDD" or "pragmatic TDD" the result is the same. I'd argue caring about how I got there is as relevant as caring about what model of keyboard I used to type it.

4 年前discuss

> it's impossible to write adequate test coverage up front

I'm not sure what you mean by this. Why are the tests you're writing not "adequate" for the code you're testing?

If I read into this that you're using code coverage as a metric -- and perhaps even striving for as close to 100% as possible -- I'd argue that's not useful. Code coverage, as a goal, is perhaps even harmful. You can have 100% code coverage and still miss important scenarios -- this means the software can still be wrong, despite the huge effort put into getting 100% coverage and having all tests both correct and passing.

5 年前discuss

Neither does squashing though: you still can't tell if that line was introduced or modified.

I've come across "fix indentation" or "fix typo" commits where a bug was introduced, like someone accidentally comitted a change (maybe they were debugging something, or just accidentally modified it).

For example: I'm tracing a bug where a value isn't staying cached. I find a line of code DefaultCacheAge=10 (which looks way too short) and git blame shows the last change was modifying that value from 86400. What I do next will be very different if the commit message says "fix indentation" vs "added new foobar feature" or "reduced default cache time for (reason)".

5 年前discuss

> "Have I made the code shorter?" is a much easier question to answer than "Have I made the code easier to understand, modify and maintain?"

This is something that comes with experience though, and I think a lot of people don't truly grok this until they are trying to maintain their own terse/clever code written months/years earlier. Nothing is quite as humbling as doing `git blame` on some crappy code only to see your own name there.

5 年前discuss

The Ubiquiti controller is not needed for general operation, unless you're using a guest hotspot. Otherwise if it's offline you just lose ability to do configuration and it's data/stats logging.

5 年前discuss

> Individually, these things are small, but the small impedances these changes introduce does take a toll on people, especially when you're trying to just get stuff done.

One of the problems is a parity disconnect. A developer/PM often has very different perspective from their users: They see the new changes as they're happening and so they're all small, incremental changes, plus they're closely following development.

A lot of users only infrequently update and/or infrequently use certain features, and so for them, all these small incremental features add up to be massive change for the sake of change. This will often manifest as "Every time I go to do x, it's totally different and I have to re-learn everything!".

I find a lot of software -- especially FOSS -- also communicates change poorly. Release notes are the primary way to get across changes, yet there are several bad things people do that make it basically impossible to read:

* List every change or commit message, especially without categorizing or simplifying the wording

* Don't properly highlight feature changes (eg with screenshots and/or reasoning)

* Have dozens of betas/pre-releases, but don't consolidate the release notes into a final "here's what's changed since the last main release" document

Some examples of exceptionally good release notes: Visual Studio Code [1], Jira [2], Gitlab [3] (though if they only provided their changelog [4] it would be a good example of being overly verbose to the point of unusable).

[1] https://code.visualstudio.com/updates/v1_52

[2] https://confluence.atlassian.com/jirasoftware/jira-software-...

[3] https://about.gitlab.com/releases/categories/releases/

[4] https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/CHAN...

8 年前discuss

Consider a line like:

    value = 1 / input;

You can get "100% coverage" if you test that with `input = 1`, but unless you check with `input = 0` you're missing a quite important logical check.