That was one of my first thoughts as well. The article sells this increase as a necessity, but with no note of whether that was to maintain profits or operating costs, further research may be required. My feeling is that it's the former though.
Noranett is a grid operator, and like most European grid operators is legally required to operate as a nonprofit. The only reason the revenue has to remain the same is because it costs the same to operate the grid. There are now just fewer people paying for it. More of a "economy of scale makes things cheap" than a "capitalism is bad".
Most electricity local distribution undertakings run on a cost plus model. If their costs increase, they are permitted to have higher profits as regulators set rates such that profits are a percentage of costs. There is no incentive for grid operators to become more efficient or to avoid needless waste. This works out great for grid operators, but means the general public can only ever expect higher prices for the same service.
I'm actually quite surprised at the initial response by the PHP Core to this vulnerability. At very least I would have thought a sensible approach would be to fail securely - so if supplied with a bad hash you return false, not true!
It looks to me like it's trying to return false on a bad hash but missed one of the three ways crypt can signal failure (returning the input unmodified).
I assume s/bit/not/. The checking function is “does the given password with the stored parameters hash to the same value as the stored hash”. Hash functions are deterministic.
So returning the original hash for a valid password is the success case.
We tried this in a team a few years ago, and the problem we faced was developers literally falling asleep during readings. We found that the Team wasn't really engaging with the process and instead just tuned out until it was their turn.
That doesn't mean I think Crockford's "Dailies" model is a poor one, it's just one issue to be aware of. Though I often find the same in Scrum teams. Folks aren't listening, they're just waiting for their turn to speak.
Dailies in film is watching not quite the final product, but still an output of the process. Maybe the issue was reading code as a team (that's code review/PR) rather than reviewing the output of the code? I think Dailies as a metaphor to me sounds like a call for more regular QA/UAT style review sessions as team. (This metaphor is new to me, but regular "use the product as a team" sessions might be quite useful, just maybe not every day.)
Though he doesn't mention it in this video, I have seen Crockford promoting the 'Dailies' idea in talks before - and he does promote it as a replacement for code review and stand up.
One hour, every morning, where the entire Team reads the code written the previous day and offers feedback. Juniors learn from seeing real-world code presented and explained, Seniors get peer review, more eyes means fewer bugs, etc.
It didn't work for my Team, but I would be interested in trying it again in future.
This has been common in the scrum ceremonies I've participated in in most of my career. The standup is primarily for keeping your manager up to date on how things are going with your estimates and maybe for asking for help from a coworker with a blocking issue.
I think what Crockford outlines here would be fantastic if it worked. Multiparty code review.
The reason it works for movie production teams is that they don’t watch dailies most working days of their career.
The film shoot is a special high-intensity time. You may spend months and months in pre-production, but the actual shoot might only be 20-30 days (on a lower-end production). Every day needs to count. If you can learn from the previous day and improve, it makes a real difference near the end of the shoot when you’ll have much more freedom to experiment.
In contrast, software engineering is more of a uniform slog. Back when software shipped in physical boxes, there used to be a marked difference between the planning, development and testing phases, but that’s gone. At many companies it’s just a grind of tiny features and endless tickets. Hard to get excited about the “dailies” for that.
Plus, if you miss a mistake in a shoot it will be expensive to fix after shooting wraps, if not impossible. Bugs might get more expensive to fix over time, but most don't, really. Not like that—not with such a very-near-future cliff after which they get far more expensive. And I'm not sure how many more you'd catch doing daily team reviews versus less-frequent targeted code reviews, anyway. The practice sure sounds brain-meltingly dull, to me, and with little benefit.
Same. I don't hate them (they last at most 10 min.), but as someone who has been working for more than 12 years in the industry I think managers/teams do daily stand-ups because of cargo cult.
It's a really boring 10 minutes though and it happens everyday. And it translates to more than 10 minutes of wasted time because of the context switch (and the added drudgery that can affect morale)
We need to accommodate human nature, not change human nature to accommodate corporate requirements. Its irrational to expect a group to rally passionately around every available task. Robotic.
After many years, defining "good at programming" is hard. I would say, reading your code is part of that. I used to read all the code that got checked-in for one of my large projects.
The other part is that you can also grow people into being good. This is one of the more important roles of big-tech where college grads come in as n00bs and become engineers.
I worked on a similar little project about 10 years ago. We called it 300 Lines. It was a shared public canvas which displayed only the last 300 lines drawn.
We used socket.io to sync between the client and a NodeJS backend. (The whole thing was really an experiment to get to grips with the then-nascent Node v0.4)
Of course it was horribly abused, and we took it down after only a few days.
Many people were upset or annoyed at the idea of their own device spying on them. I can understand that.
However, the major issue for me is the database of "forbidden" neural hashes which you are not permitted to have on your phone. Who controls what goes into that database? Right now, it's only CSAM and Apple have said they pinky-swear that if they're told to add other things they will refuse.
Any maybe they will. Maybe Tim Cook will fight tooth-and-nail to avoid adding non-CSAM hashes to that list. But then maybe Tim retires in five years time and his replacement doesn't have the appetite for that fight. Or maybe Apple gets court order saying "you MUST also report this sort of content too". Maybe that list of forbidden hashes now includes political imagery, the picture from Tiananmen Square, known anti-government memes, etc.
Once the technology is created and deployed, the only thing preventing that sort of over-reach is Apple's resolve against governmental pressure; even if you'd trust Tim Cook with your life, I can completely see why that would give people pause.
> However, the major issue for me is the database of "forbidden" neural hashes which you are not permitted to have on your phone. Who controls what goes into that database? Right now, it's only CSAM and Apple have said they pinky-swear that if they're told to add other things they will refuse.
The problem with this is that we already know "National Security Letters with Gag Orders" exist, and we know that the US government, at least, doesn't mind using those.
"You will do this thing and you will tell nobody that you've done this thing."
> However, the major issue for me is the database of "forbidden" neural hashes which you are not permitted to have on your phone. Who controls what goes into that database? Right now, it's only CSAM and Apple have said they pinky-swear that if they're told to add other things they will refuse.
This isn't what was being proposed. What was being proposed was that if you had a photo that resolved to a "forbidden" hash, upon being uploaded to iCloud data would be sent to Apple. Presumably after some arbitrary amount of times this happens, information would then be sent to the local government.
If you were not using iCloud to store photos then it wouldn't matter either way (according to Apple).
I don't think anything I've said contradicts that. Although Apple said they would only scan content which was uploaded to iCloud Photos, scanning still takes place locally on-device.
I’m not saying you made a contradiction - I’m saying that the files in question would’ve been scanned either way. The question is simply whether or not you trust and believe Apple. If you don’t it doesn’t make any difference whether it’s being scanned on device or not.
>Maybe Tim Cook will fight tooth-and-nail to avoid adding non-CSAM hashes to that list.
1) Tim Cool will have no knowledge of this when the government inevitably expands the hash list
2) Apple gets a list of hashes, not content, from NCMEC which is an unconstitutional quasi-governmental agency created by congress and funded by the government to bypass the 4th amendment.
3) Apple will simply get an updated list of hashes and has no reasonable means to verify what the hashes from any given government are.
Luke Wroblewski has long been a critic of the hamburger icon, citing both that hiding key components of your application behind a burger menu is bad for engagement [1] and that the meaning of that icon as "menu" is not as well understood as we may think [2]. These claims are a few years old now, so things may have moved on -- I would be interested to see up-to-date analysis of how users interact with and understand these icons.
> hiding key components of your application behind a burger menu is bad for engagement
It's still undecided and has become under further scrutinize lately if low engagement actually is a bad thing, considering everything.
Many of the biggest tech companies does nothing but optimizing for engagement, and hence we have viral outrages via social media. Addiction is also played as something that are good for companies, but we're slowly waking up to the notion that optimizing only for engagement was never a good idea for humanity at large.
> ...optimizing only for engagement was never a good idea for humanity at large.
I don't trust companies to have this as an incentive. Profit and revenue are the incentives, and if caring about humanity helps those, then it will considered.
> > ...optimizing only for engagement was never a good idea for humanity at large.
> I don't trust companies to have this as an incentive. Profit and revenue are the incentives, and if caring about humanity helps those, then it will considered.
Wait, are you saying that you prefer for corporations to act like amoral psychopathic profit maximizers?
I'm not sure why, but I'm in that camp too. I can only assume that there is some piece of shared past computer system experience I don't share with the hamburger menu people.
That icon has just never really been associated with 'menu' for me, so my eyesight just glides over it as if it's not there, and it just doesn't register as a UI component. (And that vertical ellipsis is even worse, doubly so if it repeated in multiple locations within a UI.
Conversely, the hamburger menu always meant "menu" for me, it strongly reminded me of a menu list, and it was the first thing I clicked/tapped when looking for options. Never understood the hate for it, even calling it "hamburger" feels like a straw man argument.
Your eyesight glides over it as if it’s not there? Oddly enough, that seems perfect from an uncluttered-design standpoint. Can you still find menus when they’re hidden behind invisible hamburgers, perhaps by association with the top of the page?
I find a gear or cog more conceptually engaging than the "hamburger".
Open it up and look at how it works inside, maybe tinker with it.
The three lines have no distinct relation to me that isn't artificial, as least the floppy icon is tied to something that might have a historic meaning. These days I'd probably have a checkmark and a broken checkmark to denote 'checked in' and 'not checked in'. Crucially it would probably need to be two checkmarks when fully checked in, and a single big checkmark in back with a smaller obviously broken one in front to denote an older version exists.
I actually never made the connection between "hamburger" and "menu" until your comment. I thought everyone chose "the three lines" for menu as a stylistic choice that everyone copied from each other.
Even though I know what the hamburger icon does and regularly use it, the example in that second video of making it more button-like benefits me, because without clear cues about what's ornamental and what's interactible, it takes more time for my eyes to find things I can click on.
"Most web analytics tools do this by excluding certain IP addresses from being counted. However, we do not store the visitors’ IP addresses in our database for privacy reasons"
GDPR doesn't care about storage. Even if you just acquired personal information without processing it, you still had to be GDPR compliant.
In fact, the solution suggested above (only using a truncated IP address) would still require you to acquire and process the IP address and thus be subject to GDPR.
I love the "Wat" talk. I wrote a blog a few years ago where I attempted to dig into the JavaScript cases Gary's cites and figure out what is actually happening.
At least one Bitcoin site is reporting the figure as $300 per year.
The Noranett press release announcing the 20% increase does not put a dollar (or krone) amount on it.