The root problem may have nothing to do with accounting but may be the backend system being used to store those passwords. If it's a large company with legacy systems maybe the passwords are being stored on a mainframe that has a fixed character length field designed a long time ago and that also maybe doesn't support certain character sets. That's a whole different problem that needs addressing but it happens more than you'd think.

Interesting. I just saw the Postcard show there earlier this week and it was mind-blowingly immersive. I've never seen anything like it. Our seats were in the 200 section, but I can imagine what you are talking about with the 400 section because none of it would really be 'around' you. I think the resolution is something crazy like 18k.

I noticed the scenes with structures in them (like the cathedral or the church spires) were warped as they followed the curve of the sphere and was wondering what they'd look like from a more central seat. For a concert, I don't think it would matter as much. Movies would be hard to show there because of the curve, I think, so that's a whole genre of entertainment they can't use.

I thought the audio was _great_ in terms of localization. When things made noise, they made noise wherever that thing was on the screen. BUT- I 100% agree that it was way too loud. My friends and I were talking about this after the show. And I also felt like the _quality_ of the sound was a bit lacking. It sounded... tinny? papery? Shallow? Boxy? Not sure how to describe it. The depth was there in terms of range but it just didn't sound quite real.

The movie itself sucked but was still worth seeing. I'd go again if I was with someone who hadn't already seen it. It was way too heavy handed and cheesy with it's 'message'. They should have given it the Blade Runner treatment and replaced the voiceovers with just music. Even better, also cut the first and last 5 minutes from it.

For people who have been to Vegas but maybe haven't seen the sphere, we also went to Fremont street and looked it up to compare the two screens. IIRC, The Sphere has somethlng like 4x the real estate of the overhead screen at Fremont street and wraps more or less around you depending on your seat. I don't know what the difference in resolution is but I can say that Fremont street looked pixelated while the sphere just... didn't. The sphere was a better display in every way which is kind of interesting to think about when you figure they're doing it all on a curve with audio emitting from behind it or embedded with it (not sure which).

I dunno. I think the sphere itself is pretty amazing but the show sucked. No one knows how to take advantage of that sort of format yet and it will take time for people to figure it out. What we saw didn't seem gimmicky in any way. It looks like it has tremendous potential but no one knows how to take advantage of it yet.

Yeah- that's true. You do have to maintain separate versions of your terraform code for different providers, which is a bummer.

The advantage over shell scripts that I haven't really seen anyone mention here directly is that terraform develops and maintains a graph model of your infrastructure state. As things change, it can figure out what infrastructure pieces need to be updated and then update them. If you are in a scenario where you have, say, a mix of cloudflare, digitalocean, and any number of other 3rd party pieces, you can use the same DSL to manage them all and you have a cohesiveness through the graph that you can't get with just shell scripts.

Having said that, I think terraform falls short with it's dsl. They tell you it's code but it's really more of a declarative configuration language, if you ask me. Some things are downright painful or impossible and there are limitations that make sense when you think of graphs but are still aggravating beyond all belief (e.g. no variables allowed in `on_destroy` blocks). Hashicorp has been pretty opinionated on changes, too. They just sort of say 'no' and shut down issues and requests. I'm hoping some of this changes with the fork.

I disagree on a couple of your points. Just calling them stupid doesn't mean they aren't valid.

- The Express option displays a shorter timeframe than the standard option, implying the express option will deliver your food faster. They are telling you that if you pay extra for the express option you will get your food faster. If that's not true, then it's deceptive.

- Similarly, the expanded range delivery spot displays the distance from you to the restaurant, indicating the distance is a factor. If this is tied to a fee, any reasonable person would assume they are paying extra because they live outside the restaurant's normal delivery area. Again, deceptive.

As for the rest, I don't know what to make of it. I know that when you add it all up it creates an overall picture of gouging and deception and maybe that's the point. A bunch of small things that may not be illegal in and of themselves might be when combined together. As for me, I think the two options that I pointed out above ARE deceptive and I'm mad about it. I've had some bad experiences with Doordash overall. I really don't like them and wouldn't use them at all if my bank didn't have a relationship with them that allowed me to avoid the `doordash fee` in most cases. GrubHub is better, but that's really not saying much because they're awful too in their own way.

I do. I'm also fairly sure I don't have the IQ of a sheep.

Debit cards do not offer anywhere near the same level of fraud protection as a credit card and they link directly back to a cash account. I don't use my debit card for anything unless I'm tapping it myself at the grocery store and am comfortable with the retailer. For everything else I use my credit card and then I pay the whole thing off once a month. Recently, I started using privacy.com and set it up to be funded by my credit card; I am starting to swap out recurring charges (netflix, etc.) for disposable numbers.

I had a subscription for awhile and eventually rage-cancelled it after getting sick of the commercials. I'd never seen so many commercials in my life. And you have no choice but to let them play out. 90 seconds here, 2 minutes there, it was completely, utterly ridiculous. Then they announced another $10/month price increase and I had enough. There was no way Hulu was worth paying that kind of money for. And now _another_ increase? Good luck with that.

I'm not sure how far you're going in your thoughts here, but I know I care about the version and there are lots of occasions when the old code ain't fine.

Falling too far behind can turn into an even larger problem down the road when you need to update software A to resolve an issue but you can't because you're too far behind and there's no longer an upgrade path because they've done something major (like switched from MySQL to PostGreSQL) on the backend. Better yet, sometimes software A (which is already behind) depends on software B (or vice versa) which is maybe even further behind. Now you're really stuck.

I think it's important to not confuse stagnant with stable; there's a point where 'stable' can become it's own enemy. Positive gain from just staying up to date with your software might include lower-risk changes months or years from now when you are forced into a hurried, unplanned upgrade to address a security need or get a new feature that you desperately need to resolve some other issue and continue your work.

I had the same reaction when I was a kid and saw The Black Hole. I own it today, and I fully agree it really is a dark sci-fi movie; it's one of my favorites.

Honestly, I prefer it over Star Wars.

As an aside, did anyone else notice that in Tron 2, when Flynn's son first enters the virtual world, makes his way onto the 'command ship' and meets (I think) CLU for the first time that the command room looks exactly like the command room on the Cygnus from the Black Hole? The little pods sunken into the floor and the ledge going around the edge? Is it the same set? I always sort of wondered if that was a nod to the other movie.

I used to think this way, then grew up and realized that tools like IntelliJ and Eclipse are useful and have features that give me more insight into the code I'm working with and help me do my job more effectively. The tool is just a tool, and any tool will let you do things you're not supposed to do if there are not processes in place to prevent it. This is where the attitude of the business, coding conventions, code reviews, unit tests and other processes come into play.

Put more simply- if this were construction, I'd say it's not the hammer's fault the house was poorly built.

I know. I was actually just trying to put into words the ridiculous cartoon that was in my head.

You raise an interesting point. I think the scenario you describe is an ideal situation for something like that, and there's value in it because you're communicating information to another group. I agree that ritual for the sake of ritual is meaningless.

Maybe the difference is that, with a morning standup, you are essentially giving yourself a shift briefing on the work you just did the day before. That alone could make it meaningless. Maybe the value of the morning meeting is proportional to the communication dysfunction within your company?

Not even close to the same thing.

Well, not unless every person in your morning company formation sequentially breaks ranks, runs to the front, does an about face and gives a personal status:

"Company! Yesterday, I did a lot of pushups! Then I low-crawled! Then I cleaned my weapon and did some more pushups! Today, I'm going to walk a lot! My impediments are the group of people across the wire trying to kill me! Hoooahh!!"

I agree with your sentiment.

I'll veer off into the woods a bit. At my company, we recently switched to scrum and it gives clear visibility into who is adding all the extra, unnecessary work and scope creep that comes with people not quite doing what they are supposed to be doing. What I really like is that it also gives developers a tool to push back with when they are asked to switch contexts, re-prioritize what they are doing or take on new work via scope creep.

Team structure seems to play a larger part in things than I hear people talk about. Trying to find a balance between inexperienced and experienced developers is difficult, and we've pretty much always come up on the wrong side of it. One of the other fundamental imbalances I've seen (at least in our organisation) is that, within the context of a sprint, the developers are usually capable of doing everyone else's job- but the reverse is not true. I've seen this turn into situations where developers end up doing BA work, QA work and supporting production issues while trying to keep up with the development tasks that are on the board. Meanwhile, everyone else is just sort of sitting around, trying to look busy. In my opinion. this is a management failing more than anything, but it is still an imbalance.

This could just be how we apply (or misapply) things, but what I really wrestle with is the idea that ultimate accountability seems to rest with the developers, but others don't seem to be held to the same standard. Agile (I can only speak to scrum) seems to provide a framework that offers to give developers more power in exchange for more accountability- but none of the processes that give the developers what they really need to deliver on what is required seem to fall under that same framework. Scrum seems to declare things like figuring out specific requirements for what you're trying to develop outside it's scope. This means that when other areas of the business don't do what they are supposed to, the developers end up having to deal with it in some capacity. Since they are the ones on the hook, that usually means doing someone else's job. Developers are motivated by the sheer number of eyes focused on them, but where is the motivation for everyone else involved in the process? Even this book review seems to only talk about rewarding (or not) developers. There isn't mention of the other groups that feed the process.

I'd also go waaaay out on a limb and argue that misapplied agile seems to have the potential to kill vision within a company. By forcing people to spend the majority of their time thinking only about what they can deal with in terms of this (or the next) sprint, it seems long-term vision with respect to a product has the potential to get lost. In other words, if there isn't a cohesive vision of what you're trying to produce, you could be reduced to a team of developers who only have the ability to react to situations and stare at the technical debt you've accumulated by switching directions so many times. That's probably a bit melodramatic- maybe that potential exists regardless, but scrum makes it easy to see how that could happen.

Ok, enough ranting.

Part of the reason may be that the back-end storage for that particular site is a legacy system and limiting users to ASCII characters ensures that the byte length of all entered characters is exactly the same. Otherwise, a user might be using a charset that provides for umlauts or something. In UTF-8, for example, the higher order characters could use 2, 3 or 4 bytes of storage.

Assuming you are on a website, your password could still pass form validation because the character length passes muster, but behind the scenes you are using more bytes than anticipated. This could cause the stored data to extend beyond the length of the column, causing the DB to truncate the stored password and therefore corrupt it.

This just sort of jumped out at me...

'Apple is driven by someone who has some understanding of end-user needs, Linux is not.'

Linux _is_ driven by someone who has an understanding of end-user needs. The Linux end user just happens to be programmers and sysadmins. Why does something have to be reduced to the lowest common denominator to be considered a success?

To put it a bit differently (and paraphrase a famous quote), Linux is user friendly- it's just picky about who its friends are.

If you like Perl, you'll love Perl 6.

I forgot to say that Perl 6 is not ready yet. The language itself is not fully defined, and if there's anything you'd like to change in Perl 5, you can post your ideas on Perl 6 mailing lists.

So I can't use Perl 6 yet, still it's already my favorite language, like Parrot is my favorite virtual machine, The GNU Hurd is my favorite kernel and MMIX is my favorite CPU. I can't wait to use them all one day.