> The feds forbid LE.
Nope! Very much allowed -- at least for almost all applications.
Here's just one example from a quick Google search that turned up lots of others: https://www.digitalgov.gov/2016/09/07/lets-encrypt-those-cna...
878 karma · joined February 11, 2011
Nope! Very much allowed -- at least for almost all applications.
Here's just one example from a quick Google search that turned up lots of others: https://www.digitalgov.gov/2016/09/07/lets-encrypt-those-cna...
One thing I've found that's drastically cut down on the frequency (possibly eliminated it? not sure) is this: Always wait ten seconds between display state changes. Waking the computer up from sleep? Wait ten seconds before you dock it or connect an external monitor. Undocking it? Wait ten seconds before putting it to sleep.
Also: never make more than one state change at a time. For example, don't put the computer to sleep while docked, then undock it. Undock it first, wait ten seconds, then put it to sleep.
YMMV, but like I said: I think this has eliminated this problem for me. I've been using this process for some months now, and I'm doing much better at the uptime game (28 days since my last restart, right now).
Now, we can argue about where the balance is best struck, whether it's better to have the president making decisions vs. individual government workers, etc. Those discussions are fine. But we nerds have to stop pretending that a nation's laws are or could be or even should be as black and white and bug free (hah!) as most computer code.
What's often needed for robust systems, instead, is solid support for error handling such that "if this bit doesn't make it in, then neither does that bit." Data is always messy and dirty, and too many ETL systems don't seem architected to cope with that reality.
Of course, maybe I just haven't found the right tools. Anyone know of tools that handle this particularly well?
$ watch --interval 0.1 --no-title date
;)
Maybe this will be helpful? Here's the Ansible config I've built for a Jenkins deployment I manage: https://github.com/HHSIDEAlab/hhsdevcloud-ansible/tree/maste.... Most of the "meat" is in the Groovy scripts in the templates/ directory there.
I think it's far more likely that any movement towards C# on Android would be motivated by: 1) perhaps enough devs are asking for it, and 2) it would give them extra leverage in negotiations with Oracle about Java.
It seems... at least a bit arrogant for a developer that doesn't write any of the languages that rely on these features to claim that they're insane and excessive.
Which SSH does support, btw.
The trick is in threading the needle on this one. In my experience "shipping" doesn't need to be a binary operation. Seek out your early adopters as soon as possible, get your product in front of them, and take their (hopefully) constructively blunt feedback to heart. Ask them what's needed to make it truly usable for the rest of your users.
I've certainly worked with a lot of folks who didn't, but I guess I've just always hoped that experience was unique to me.
> It’s worth repeating that what’s generally overlooked is that each decision was made by the team and a variety of alternatives were considered. Moving forward with Wasabi .NET was only done after considering a lot of alternatives, including porting to python.
That right there is the crucial point for me. I think the real danger (and concern) with these types of technical debt situations is that they're often forced on engineering by upline management (i.e. non-coders). But if the folks who will have to maintain any mess they create are the ones making these decisions, the decisions are likely the correct ones-- at least at that time.
Aside from its code formatting rules, which are just silly. They're easy enough to modify or turn off, though, so there's that.
Of course more time was spent editing files with more lines of code. In fact, if your entire application was all contained in one file, I am willing to predict that you'd (shockingly) find that all of your time was spent editing that very same file!
I believe this is what the GP poster is mentioning when he says that there often isn't "sufficient time to withdraw."
1) Every day. I've seen this with working out, side projects, or whatever... I can't stick with commitments if I try for an "every other day" or "only weekdays" strategy. Has to be every day. [1]
2) Track it in a visible fashion. GitHub's contribution calendar is fantastic for this. I've got a text file named 'work-log.md' in my side project's folder, and I update and commit that file whenever I spend time on my side project-- even if all that I did that day was research, rather than coding. My current high score/longest streak is 59 days in a row, and wanting to push that higher is incredibly motivating. With workouts, some sort of fitness tracker serves the same purpose.
3) I don't beat myself up too long or hard about screwing up. There are some folks whose "longest streak" on GitHub is 365 days or more. Good for them! I'm always sad when I realize I've missed a day, and I often take a break for a week or two once that happens, but I've never even thought about just quitting. Just motivates me to try and do better next time.
[1] One exception to this was biking to work: I never really biked on the weekends, but it didn't prove to be a problem. Probably because commuting by bike was so hard to forget about.