618 karma · joined April 6, 2012
The standard library has lots of side-effecting methods which don't come with ! suffix. On the same Array type that has reject!, there's delete, pop, push, among others. Only some of them have pure equivalents - e.g. last for pop.
A peeve I have with Ruby is that methods in the standard library don't have defined big-O complexities. If they did, I don't think reject! would have been specified to be O(n²), and so it would be a bug.
I believe Google's (and Amazon's) secret sauce is having large sysops and devops teams filled with subject matter experts - and the software's original developers.
Efforts like Torus are trying to build zero-to-low-maintenance turn-key solutions, whilst Google is happy to have tens of full-time distributed storage engineers.
Some package management systems can decouple what packages are called inside the code from what they're called outside.
Don't work from coffee shops. That's just a bad idea anyway, as your CSO will tell you.
> Three days at home and you feel like a loner.
Nope. I work from home 4 days out of 5, and I'm constantly in communication with my workmates. I also have friends outside of work. Even then, I like being alone. Don't hire autophobes to work remotely!
> Face-to-face meetings are most efficient
I hear people say this, but rarely do I see evidence. Informal face-to-face meetings often end faster, but they often leave important issues unexamined. Face-to-face meetings also prevent everyone from working when they're happening. With email and even instant messaging, I can participate in a conversation even if I'm not available when somebody else wants to start it.
> Technology is always iffy. In meetings, it boils down to Wi-Fi speeds, audio quality, and lags
Learn to use text to communicate. IRC/Slack works fine over slow connections. Plus, the minutes write themselves!
> Remote work doesn’t allow for quick adaptation or response to ad hoc issues.
Your remote workers should have phones. Reserve them for when you actually need to contact them urgently and they won't just ignore them.
> Some PMs are understanding of time zone differences and ad hoc travel reschedules while others prefer fixing meeting times and office hours.
This is a problem with your PMs. You can't have remote working whilst allowing PMs to run projects in a way that's not compatible with it.
> Balls are dropped or people reinvent the wheel because they are unaware another team member has taken action already.
Anyone who's worked in an office will know that also happens in an office. It's important to have a method of tracking what work is being done, or not being done, whether or not everyone is in the same office, unless your company is 3 people sitting around the same desk.
Having said that, the reports I've seen contain scant actual evidence that Google actually plan for Andromeda to replace Android, or even that Andromeda is at all important to Google. I take these reports with a mountain of salt. I remember that the "Pixel 3" was definitely just about to be announced back in late 2016, and was definitely going to be running Andromeda OS.
You can't. Google aren't selling your personal data to anyone. That's antithetical to their business model, which involves them having all the data.
They are selling your eyeballs to advertisers, and using your personal data to enable advertisers to very precisely target the demographics they think want to see their adverts. Not that this works.
Alt-click adds a cursor. :)
Also, alt-up/down adds cursors above or below the current cursors.
Parliament is in fact sovereign, and always has been. EU court decisions apply in the UK exactly to the extent that the UK government permits them to. e.g. When EU courts rule that UK prisoners have to be allowed to vote in UK elections, the government ignores that.
When it ascents to unpopular EU laws, it does so voluntarily, after having been involved in drafting them, something people would be wise to consider when imagining that "returning sovereignty" to the government will magically fix everything.
This is a pipe dream. For anything significantly non-trivial, programming is inherently complex. Designing the language so that code is forced to be "simple" at the lowest scale just pushes that complexity up to larger scale code structures.
Trying to make programs easier to understand by limiting the expressivity of the language is like trying to make quantum physics easier by reformulating it without using complex numbers. Whilst it may well make each individual step of a calculation easier to understand, it doesn't make the whole any easier to comprehend.
x := 1.0
y := ValueMeters(1.0)
x + y // Mismatched types error - ValueMetres and float64
Because Go doesn't believe in operator overloading, there isn't even anything you can do about it. You have to abandon the pretence and explicitly convert the values to the same type.Go does a little magic with literals in that it will implicitly use explicit conversions on them to satisfy type constraints, so ValueMetres(1) + 1 works, but ValueMetres(1) + float64(1) does not. (Otherwise you end up with annoyances like not being able to add "1" to a float.)
This gets particularly gnarly when interacting with libraries which expect the underlying type you're wrapping:
x := ValueMetres(math.Sin(float64(x)))It also communicates exceptions via option types, and - by convention - functions that can go wrong return an instance of Result<SuccessType, ErrorType> initialized either with a success value or an error value.
There are some helper methods on Result. I like "expect", which panics if an error is indicated and returns the success value otherwise. The real boilerplate removal comes via try!, which returns the result (actually it re-wraps it in a new Result) if it's an error. When used on functions that can fail inside functions which return Result, the result is that try! bubbles the exception up the stack.
The experience is very like traditional exception handling, but you always know exactly how control can flow, since try! only returns from the function it is directly inside, and can only from functions which advertise that they can fail by having Result<> as their return type.
Your second sentence answers your first. Not everyone likes writing the same code over and over again, even if it's simple code.
> generics seem like a pretty easy thing to write a preprocessor for
Very funny. But even if it were possible, the bigger problem with using a preprocessor is that everyone ends up using their own incompatible generics preprocessor.
The GM only needs to come up with an idea that works for their group of - say - 4 players, whereas the MMORPG vendor also needs to come up with artwork and code and ensure that the content is balanced for thousands - or more - of players at different stages of development and with different playing styles.
MMORPGs feature grind because without it the players would run out of content before new content was available: then they'd get bored and quit. Or, if the content was produced quickly enough, it would likely lack sufficient quality control and players wouldn't like playing new content, with the same result.
Of course, the more money the vendor is able to put into creating new content, the less grind the game needs to depend upon. And if the game has many social players, their social interactions provide another mechanism to keep players interested after they run out of content. Eve is a good example of an MMO where player interactions are a big part of what keeps players in the game.
If you had a canary for 0-99, 100-199, etc, and then removed the canary that didn't match, a court might decide that your decision not to assert that you didn't receive 0-99 canaries was as good as asserting that you did receive 0-99. Whereas, if you have a general canary, you can say you removed it because you just didn't want to use a canary any more.
Having said that, I suspect that a court that's sympathetic to the government might well decide that choosing not to speak is itself an act of speech, and that even if you can't be forced to restore a warrant canary, you can be prosecuted for removing it.
Searching online, the easiest results to find seem to be either to manually uninstall hardware-specific drivers in the device manager, or simply to assume that motherboard upgrades will just magically work. Whilst one can find results that mention sysprep, how is a user to know that the sysprep method is the right one?
And now I read:
When sysprepping an existing Windows setup, it only works if the Windows was installed clean and has never been upgraded or repaired using repair install.
So that's great.
For the high-level layout elements it's not so bad, but the <i> element being defined as indicating things such as "taxonomic designation, technical terms, foreign idioms, transliterations, thoughts, ship names, or dream sequences" renders it basically pointless. The HTML spec encourages you to use a class attribute to identify why <i> is being used, but then you might as well use <span>.
Most browsers - maybe all modern browsers - actually accept made-up elements and let you apply CSS to them. There's no good reason - other than compatibility - why authors shouldn't create ad-hoc elements - e.g. <dream> or <tabs> - that match up with the true semantics of the content.
2. CSS only almost exposes the HTML table layout system. e.g. There are no column groups, or column or row spans. There's no way to indicate a table header in CSS that would make a browser repeat it when printing a table over multiple pages.
3. People who learn by rote that table is evil without really learning why are likely to assume that using CSS to make something behave (almost) like a table is also evil.
One significant difference is that you can just look at a drawing and know if it's okay or not. There's no test suite for graphic art. Drawing outside the lines is a stylistic choice. Compiler errors are not.
The stuff a graphic artist will be fastest at, and for which estimating will be easiest, is stuff they've done thousands of times before. Most programmers aren't writing code they've written thousands of times before, unless they're not paying attention.
Out of the creative arts field, I think programming is probably most like creative writing. The grander the program, the grander the equivalent narrative. Unlike a picture, you can't just look at a book and know if it's written properly, you have to read it through. Not only do you have to worry about grammar, you also have to be concerned that the narrative is internally consistent, and that it features the themes, characters, and dramatic situations specified in the brief.
Of course, the analogy still isn't exact. A novel doesn't actually have to be internally consistent, and the book doesn't crash if there are spelling mistakes. In fact, many novels written without taking spending the time and money to edit it properly will have plot holes or grammatical errors. A reader can fuzz past it, but a computer can't.
Ask a writer how long it will take to write a novel that is totally internally consistent, leaves no plot threads unresolved, and has no grammatical errors. They'll tell you it can't be done to schedule.
A properly run business cares about selling products tomorrow but also cares about selling products next year. A properly run business therefore invests time in quality engineering so that the products they build now still work next year, or can be easily modified to fit whatever next year's requirements are.
It's just good sense. Rushing out a horrible bodge job is only okay if you don't plan to be in business after the holiday rush, or at least not the same business. Otherwise, if you're doing the minimum viable work to keep the company ticking over from day to day, you'll usually find that the quickest way to do it today makes for more work tomorrow when you have to undo whatever horrible kludge made it work.
There's a quote I like from Dave Thomas, one of the original codifiers of "Agile": When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.
I dunno.
Maybe ask an executive at one of the many companies that have scientists or mathematicians on staff how they do it.
When managerial "scientists" can achieve anything even remotely comparable to that level of reliability and reproducibility, it will be time to take it seriously as a science. Until then, it just isn't one.
Now, Snowden isn't a judge, nor would he have had complete knowledge of what was going on. He couldn't have known for sure that the activities were illegal.
But, unless you take the view that Snowden maliciously revealed activities he actually believed were legal, he at least had reasonable suspicions that they weren't. The job of somebody to whom whistleblowers report is to take that seriously.
Perhaps, in many cases, the reasonable suspicions are unfounded. Perhaps there is a byzantine legal framework in place that makes apparently illegal activity technical legal. Perhaps Snowden's concerns had already been raised by others through the proper channels, investigated, and found to be unfounded.
Regardless of that, we know that in this case some of the things Snowden reported on were illegal, and that going by the "proper channels" did not result in illegal activity being detected and stopped.
Unless we imagine that Snowden is lying about having tried to report it to the agency first, and that nobody else amongst the hundreds of thousands - speculatively: the true number is classified - of NSA employees and contractors had both the knowledge of illegal activity and enough concern about it to report it through the proper channels.
Whatever the case. The part of the NSA that is tasked with detecting and preventing illegal operations hasn't done that for what appear to be some pretty big operations.
Either it didn't care that the operations were illegal, it didn't know they were illegal, or it didn't even know they were happening. None of those possibilities reflect well on the watchdog.