Live data from Hacker News

A URL Lengthener

aaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.com

221–230 of 313 posts

Re: A URL Lengthener

#221
post #203

Earlier quoted context omitted.

Below is a link I generated for https://twitter.com/home http://www.5z8.info/winamp-cracked.exe_x8c5se_how2pipebomb Thank you for this, I laughed hard.

That totally reminds me of this story: http://www.5z8.info/awesome-real-life-headshots_q2h6fv_linke...

That's like a whole level extra of sad because it's not that someone was oblivious to list context in perl, but that they knew about it but didn't quite get it right.

Or, it was purposeful, and he liked how it left out the attributions to single line quotes or made a weird half-aside out of multi-line ones, and it's just another case of someone not realizing put some random content up under your own name can lead to problems. Also sad, but less unique.

Re: A URL Lengthener

#222

Earlier quoted context omitted.

The multiple efforts thing is a lesson I should learn but refuse to do. It just feels so spammy. I don't want to touch that world intentionally but it works. It gets worse I had two similar services, one that used a page's meta information to create URL stubs so that the link would have the semantic meaning in it instead of say "id=27158278". It'd also (this is about 10 years ago) fill in opengraph holes if found and…

I don't understand. Are you the creator of the other service?

The site in question here? no.

It's more like you work on something that flops and you see similar things get traction.

There's bookshelves full of analysis on this problem. I've got a few of those bookshelves in my library, a major preoccupation of mine for maybe 15 years.

But one of the legitimate reasons the big books don't touch upon is the agitation and hustle game. Probably because those authors just do it without thinking about it.

Geoffrey Moore, Steve Blank, Clayton Christensen, there's a certain aggrandizing precocity they all have that they seem to look past. It's somewhere on the road to carnival barking and clickbaiting.

The line on that road that I refuse to cross is likely way too conservative.

In fact I've had things that became popular by other random people playing that game who I've never met, just for the social cache or whatever endorphins that thing does for those people.

That's the core strategy of virality and trying to hook influencers.

It's a trend I've been noticing within the past 6 months or so. When something catches I'll do some research and find an almost irritating number of failed nearly identical attempts.

The "one note band approach" looks like it's a decent strategy, I just have to get over how objectionable it feels to me.

Being a bit more shameless doesn't necessarily always appear to be a bad move

Re: A URL Lengthener

#225
post #87
post #60

Earlier quoted context omitted.

Having written two apps that do this, I can confirm that it is an amazing technique, and criminally underutilized! My projects store and render entire pages from the URL and encrypt URLs (respectively): https://github.com/jstrieb/urlpages https://github.com/jstrieb/link-lock

Love it! Have you thought about having a non-obfuscated pretty version? In addition to this: https://jstrieb.github.io/urlpages/editor/#eyJjc3MiOiJ3aG9tI... Offer a pretty version like: https://jstrieb.github.io/urlpages/editor/#html...html-here.~css...body;background:red;~javascript...document.write('this-was-written-by-javascript.')

I appreciate the kind words!

Hadn't considered it originally because I was concerned about allowable characters in the URL, and jumped to base64 instead of leaning more heavily on the actual set of acceptable characters to make it readable.

In hindsight, this is a great thing to add to my next project that (inevitably) uses this technique, thanks!

Re: A URL Lengthener

#226

Earlier quoted context omitted.

Enterprise developer here. Exactly this. If you reject the spec, you won't get another one before the deadline that was committed before you got the spec you want to reject.

Instead of implementing the obvious intention of the spec and waiting to see if anyone complains?

The intention usually isn't obvious. The stakeholders have spent so much time documenting, in depth, the solution that they want, while spending no real time documenting or communicating the specifics intricacies of the -problem-.

That's the issue in a nutshell; Checkbox Driven Development implies "if we just define the solution well enough upfront, we'll get what we need!" instead of "if we define the problem well enough, and let dev pitch us solutions, and iterate as we go, we'll get what we need". Which implies that the devs are not to be trusted to come up with a solution themselves.

To deviate from expectations and be congratulated, you have to, A. Be certain you're doing the right thing, and B. Have an audience that can recognize you did the right thing. Both of those require a level of trust that is just missing in this sort of org.

Re: A URL Lengthener

#229
post #16

> Disclaimer: Since there is a maximum letter count to a URL, there is a slight chance your resulting URL will be too long to use. No worries, try running it through a site like bit.ly and then paste that one over here. Every resulting URL ends up having a minimum number of characters, so your URL will still be plenty long! This seems like something you can trivially solve yourself. Is there any good reason why you p…

There isn't really "a" maximum count. There's a variety of enforced limits. If the standard(s) even set an official one, it's not something a lot of things pay attention to. You also can encounter problems with things like command lines enforcing their own limits, making a URL that your browser may or may not be happy with not be something you can directly curl or wget.

I never found an RFC documenting an URL size limit.

Re: A URL Lengthener

#230

Earlier quoted context omitted.

Instead of implementing the obvious intention of the spec and waiting to see if anyone complains?

The intention usually isn't obvious. The stakeholders have spent so much time documenting, in depth, the solution that they want, while spending no real time documenting or communicating the specifics intricacies of the -problem-. That's the issue in a nutshell; Checkbox Driven Development implies "if we just define the solution well enough upfront, we'll get what we need!" instead of "if we define the problem well e…

Exactly, and sometimes to fix the issues with the spec you'll have to go far enough off script that it gets very obvious to people you dont want attention from.
Post reply on HN