The problem with this is that when I hold and press "a" in the address bar on mac at least alternate characters menu pops up instead of the key being repeated. I'd suggest this new domain:
1234567890qwertyuiopasdfghjklzxcvbnm.com
A URL Lengthener
aaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.com
131–140 of 313 posts
Re: A URL Lengthener
#132Earlier quoted context omitted.
I was on a 12-person failed project, the kind of which you owe millions to the govt. We had a problem with the search, we couldn’t get performance. I told my boss: “See, they wrote ‘The old search responded in 2 seconds. The new search must take at least the same time.’ We could almost add a sleep(2000) before starting the search.” He went with it. They dealt to drop the requirement on the performance of the search o…
Ah yes. Checkbox Driven Development. AKA Monkey Paw Development, where you give exactly what was asked for; it remains surprisingly popular in the government and enterprise spaces.
"Monkey Paw Development" was a new one for me :) Thank you! Great analogy. Reminds me of this :D https://www.youtube.com/watch?v=cDA3_5982h8
Re: A URL Lengthener
#133Earlier quoted context omitted.
Ah yes. Checkbox Driven Development. AKA Monkey Paw Development, where you give exactly what was asked for; it remains surprisingly popular in the government and enterprise spaces.
I've worked in such places. The reason it is that way is because you will receive a broken description/specification/story of what you are supposed to implement. You have a choice to make when that happens, you either implement it as specified or you reject it because it is broken. The problem is that if you do reject it then it will take about 6 months to get back a specification that is broken in another way and th…
I've been there too, and I know. I'm not speaking to the choices devs make (rock and hard place, as you say), but the choices the org makes. For government work is driven by Congress' procurement process, but for enterprise is entirely on upper leadership's perceived need to avoid risk. Which is ironically hilarious, since such approaches guarantee higher risk, in that they pretty much universally lead to late delivery of broken features.
Re: A URL Lengthener
#134A handy link to this discussion: https://aaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa...
I clicked on your link, half expecting to get rick-rolled, and was pleasantly surprised to find myself back on this same page.... but also kinda disappointed. :) +1 for avoiding the temptation.
I miss getting Rick Rolled.
Re: A URL Lengthener
#135Earlier quoted context omitted.
I clicked on your link, half expecting to get rick-rolled, and was pleasantly surprised to find myself back on this same page.... but also kinda disappointed. :) +1 for avoiding the temptation.
I'd bet 30% of the URLs it lengthens are rick-rolls. I did it immediately and sent it to several people on Slack.
Noice!
Re: A URL Lengthener
#136Earlier quoted context omitted.
I don't know. There's a lot of problems but to me "at least" sounds like a more helpful phrasing. Browsers run in such heterogeneous compute environments (even back then) that "up to" basically cripples you to the lowest common denominator of all platforms you target. "At least" makes it mostly the HW vendors problem. Sure, MS was encountering this problem more because Windows ran on such a large range of HW but thin…
The URL can be up to 1024 characters. The browser must support at least 1024 character URLs. They're 2 sides of the same coin, but MS didn't actually rephrase the sentence properly. Their version would have every URL have at least 1024 characters in it. Any less than that, and the browser should reject the URL as invalid.
[deleted]
Re: A URL Lengthener
#137Earlier quoted context omitted.
Requirements are hard upfront, period, to the point I'd say that any organization trying to set them upfront is dysfunctional, tautologically. Making all the decisions when you have the least amount of information is a Bad Idea.
but there are some architectual significant requirements, which have to be known upfront.
I both agree and disagree with you.
There are requirements that will affect architecture that, if they're guessed at and turn out to be wrong, will lead to massive refactoring and/or large amounts of effort being thrown out. 100%.
Where I disagree from most businesses is in the implicit belief they have that seems to be "better for devs to be idle than for devs to work on code that will be thrown away". I'd rather take a guess and start work; best case we're right and are ahead; worst case we're wrong and have learned some useful lessons.
Which you'll note is the same dilemma as every other decision related to the project, with the only difference being the scope.
Re: A URL Lengthener
#138Earlier quoted context omitted.
I clicked on your link, half expecting to get rick-rolled, and was pleasantly surprised to find myself back on this same page.... but also kinda disappointed. :) +1 for avoiding the temptation.
I miss getting Rick Rolled.
Here you go, sweetheart. https://aaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa...
Re: A URL Lengthener
#139This is the kind of project we need more of. No politics, no perverse economic incentives. Just one human helping other humans utterly obliterate their address bar.
Re: A URL Lengthener
#140Earlier quoted context omitted.
Ah yes. Checkbox Driven Development. AKA Monkey Paw Development, where you give exactly what was asked for; it remains surprisingly popular in the government and enterprise spaces.
"Monkey Paw Development" was a new one for me :) Thank you! Great analogy. Reminds me of this :D https://www.youtube.com/watch?v=cDA3_5982h8
Yeah, I just coined it while making the post. :P Less a "also (currently) known as" and more of a "also (should be) known as". Certainly how I'll be referring to it in cynical moments from here on out.