5 ms·

> Anyone can write a rough command line tool that monitors the clipboard and prints to stdout. There's a good chance that this will solve 95% of all needs. Mo

> Anyone can write a rough command line tool that monitors the clipboard and prints to stdout. There's a good chance that this will solve 95% of all needs. Most of the features suggested in the article beyond the original premise are unnecessary.

moksly 5y ago
Except it isn’t supposed to log things that aren’t urls being pasted into the browser.
- marcellus23 5y ago
  So? In any decent programming environment, checking if a string is a URL is a one liner
  - dkdbejwi383 5y ago
    Not without false-positives. E.g., is "foo.bar" a URL? Maybe. But it could also be a filename. How do you know if it's a "real" URL or not?
    - toyg 5y ago
      In The Good Ol' Times, I would have replied "let's check the TLD", but now that list is basically trending to include the entire English dictionary... so I guess the only response these days is "ask DNS". So we've already gone from "pattern-match a string" to "pattern-match then make network calls", which (as anyone who's done any network work knows) also requires managing a bunch of possible/likely error states (offline, timeout, partial response, response format, etc etc). So yeah, nothing is as easy as it looks.
      - AstralStorm 5y ago
        Can't quite do this most of the time due to privacy concerns. Leaking random URL-looking text to the network is a big no.
        toyg 5y ago
        So now we have to ask for user consent (installation time? first run?) and respond accordingly, adding another piece of UI... but it will only take an hour, right...?
        dkdbejwi383 5y ago
        You probably also want a setting to detect slow networks and disable it there in case the user is tethering etc.
    - quesera 5y ago
      Strictly speaking, a URL begins with a scheme followed by a colon. Schemes can be registered with IANA (or not), and everyone knows the most common half-dozen or so. People often forget "mailto:" and "tel:". The project brief asks for one thing, but the practical implementation probably requires something else. This is a good lesson to learn, and this is how two hours becomes two days, becomes two weeks.
    - tremon 5y ago
      It isn't a URL. As per RFC 3986 [0]: > The term "Uniform Resource Locator" (URL) refers to the subset of URIs that [..] provide a means of locating the resource by describing its primary access mechanism Since "foo.bar" does not describe an access mechanism, it is not a URL. Yes, you could make the argument that "foo.bar" is a relative-path reference as described in section 4.2, but that is only used to: > express a URI reference relative to the name space of another hierarchical URI So "foo.bar" can only be considered a URL in the context of another given URL, and in your example there is none. [0] https://datatracker.ietf.org/doc/html/rfc3986#section-1.1.3 https://datatracker.ietf.org/doc/html/rfc3986#section-1.1.3
    - marcellus23 5y ago
      I don't have to worry about that, because I'll pick a language that offers a `URL` object or something similar, and which handles the validation for me. Additionally, if foo.bar were a valid URL, then I would expect it to appear on the list. I can't read the user's mind as to whether the text should be treated as a URL or not.
- Jensson 5y ago
  A naïve url detector isn't hard to write. A good url detector is difficult not because it is hard to code but because it is hard to understand what behaviour a user would expect.
- Thorrez 5y ago
  >being pasted into the browser. Not just the browser: >links that I send to people across all the different messenger apps I have installed. The article does say it might be useful to log where the URL was copied from, and potentially also where it is pasted to: > I would also expect to know where the URL was copied from. I.e., whatever application is in focus when the clipboard is modified. It probably isn't feasible though to track everywhere it is pasted (maybe it is actually...).
DeathArrow 5y ago
>There's a good chance that this will solve 95% of all needs. Most of the features suggested in the article beyond the original premise are unnecessary. The teacher is the client. The client is the one who will better estimate what is necessary or not. If you own a company and someone wants to contract you for work, you start explaining how what the client says it needs is not necessary and how he can manage with less than he demands?
- IanCal 5y ago
  > If you own a company and someone wants to contract you for work, you start explaining how what the client says it needs is not necessary and how he can manage with less than he demands? Absolutely, you don't just build the first thing that the client asks for. And certainly not as a single main deliverable.
- q-big 5y ago
  > The teacher is the client. The client is the one who will better estimate what is necessary or not. If you work in a consulting company, it is "good practice" to "convince" the client that he needs a lot more features so that you can sell him more man-days. On the other hand, if you get payed a fixed price, incentives are turned around. Incentives matter.
- tomrod 5y ago
  > you start explaining how what the client says it needs is not necessary and how he can manage with less than he demands? Sometimes, yes, it is necessary to coach a client. It takes trust, but it isn't unheard of.
  - makapuf 5y ago
    Especially if you're an in-house consultancy
- sbierwagen 5y ago
  Every idiot with a stupid idea for a piece of software is a client, but vanishingly few clients are good customers. In different words: there are tens or hundreds of thousands of people who can describe software that would be very useful for them, but very few of those ideas would be profitable to fully develop. Opportunity cost! Every stupid idea implemented snuffs out what could have been a good idea.
bayindirh 5y ago
Reaching to first 90% is easy. Remaining 90% is the hard part. As the saying goes: The 90% of the project takes 90% of the time. Remaining 10% takes 90% of the time.
- deleted 5y ago
  [deleted]
TheOtherHobbes 5y ago
One of my CS teachers actually said "The programming is always the easy part. Designing the features and the interface usually takes 95% of the time."
- AstralStorm 5y ago
  Your CS teacher never looked at a web browser from the inside, or at other actual big scale software.
  - mwcampbell 5y ago
    Still, the teacher is right for most user-facing software that most of us will ever write.
  - naasking 5y ago
    I'm not convinced. If designing the features and interface weren't so challenging, why do the user interfaces and other development APIs to web browsers still change 30 years after they were first invented?
  - HelloNurse 5y ago
    A web browser might have a higher density of advanced algorithms (than most software, but only because it has unusually extensive, varied and complex requirements (e.g. a number of complex standards like HTML, JavaScript, CSS, WebGL) and unusually high quality standards (foolproof, high performance, standards compliant, secure...),
  - JasonFruit 5y ago
    Or maybe they were exaggerating for emphasis, as humans do.

moksly 5y ago

Except it isn’t supposed to log things that aren’t urls being pasted into the browser.

marcellus23 5y ago
So? In any decent programming environment, checking if a string is a URL is a one liner
- dkdbejwi383 5y ago
  Not without false-positives. E.g., is "foo.bar" a URL? Maybe. But it could also be a filename. How do you know if it's a "real" URL or not?
  - toyg 5y ago
    In The Good Ol' Times, I would have replied "let's check the TLD", but now that list is basically trending to include the entire English dictionary... so I guess the only response these days is "ask DNS". So we've already gone from "pattern-match a string" to "pattern-match then make network calls", which (as anyone who's done any network work knows) also requires managing a bunch of possible/likely error states (offline, timeout, partial response, response format, etc etc). So yeah, nothing is as easy as it looks.
    - AstralStorm 5y ago
      Can't quite do this most of the time due to privacy concerns. Leaking random URL-looking text to the network is a big no.
      - toyg 5y ago
        So now we have to ask for user consent (installation time? first run?) and respond accordingly, adding another piece of UI... but it will only take an hour, right...?
        dkdbejwi383 5y ago
        You probably also want a setting to detect slow networks and disable it there in case the user is tethering etc.
  - quesera 5y ago
    Strictly speaking, a URL begins with a scheme followed by a colon. Schemes can be registered with IANA (or not), and everyone knows the most common half-dozen or so. People often forget "mailto:" and "tel:". The project brief asks for one thing, but the practical implementation probably requires something else. This is a good lesson to learn, and this is how two hours becomes two days, becomes two weeks.
  - tremon 5y ago
    It isn't a URL. As per RFC 3986 [0]: > The term "Uniform Resource Locator" (URL) refers to the subset of URIs that [..] provide a means of locating the resource by describing its primary access mechanism Since "foo.bar" does not describe an access mechanism, it is not a URL. Yes, you could make the argument that "foo.bar" is a relative-path reference as described in section 4.2, but that is only used to: > express a URI reference relative to the name space of another hierarchical URI So "foo.bar" can only be considered a URL in the context of another given URL, and in your example there is none. [0] https://datatracker.ietf.org/doc/html/rfc3986#section-1.1.3 https://datatracker.ietf.org/doc/html/rfc3986#section-1.1.3
  - marcellus23 5y ago
    I don't have to worry about that, because I'll pick a language that offers a `URL` object or something similar, and which handles the validation for me. Additionally, if foo.bar were a valid URL, then I would expect it to appear on the list. I can't read the user's mind as to whether the text should be treated as a URL or not.
Jensson 5y ago
A naïve url detector isn't hard to write. A good url detector is difficult not because it is hard to code but because it is hard to understand what behaviour a user would expect.
Thorrez 5y ago
>being pasted into the browser. Not just the browser: >links that I send to people across all the different messenger apps I have installed. The article does say it might be useful to log where the URL was copied from, and potentially also where it is pasted to: > I would also expect to know where the URL was copied from. I.e., whatever application is in focus when the clipboard is modified. It probably isn't feasible though to track everywhere it is pasted (maybe it is actually...).

DeathArrow 5y ago

>There's a good chance that this will solve 95% of all needs. Most of the features suggested in the article beyond the original premise are unnecessary. The teacher is the client. The client is the one who will better estimate what is necessary or not. If you own a company and someone wants to contract you for work, you start explaining how what the client says it needs is not necessary and how he can manage with less than he demands?

IanCal 5y ago
> If you own a company and someone wants to contract you for work, you start explaining how what the client says it needs is not necessary and how he can manage with less than he demands? Absolutely, you don't just build the first thing that the client asks for. And certainly not as a single main deliverable.
q-big 5y ago
> The teacher is the client. The client is the one who will better estimate what is necessary or not. If you work in a consulting company, it is "good practice" to "convince" the client that he needs a lot more features so that you can sell him more man-days. On the other hand, if you get payed a fixed price, incentives are turned around. Incentives matter.
tomrod 5y ago
> you start explaining how what the client says it needs is not necessary and how he can manage with less than he demands? Sometimes, yes, it is necessary to coach a client. It takes trust, but it isn't unheard of.
- makapuf 5y ago
  Especially if you're an in-house consultancy
sbierwagen 5y ago
Every idiot with a stupid idea for a piece of software is a client, but vanishingly few clients are good customers. In different words: there are tens or hundreds of thousands of people who can describe software that would be very useful for them, but very few of those ideas would be profitable to fully develop. Opportunity cost! Every stupid idea implemented snuffs out what could have been a good idea.

bayindirh 5y ago

Reaching to first 90% is easy. Remaining 90% is the hard part. As the saying goes: The 90% of the project takes 90% of the time. Remaining 10% takes 90% of the time.

deleted 5y ago
[deleted]

TheOtherHobbes 5y ago

One of my CS teachers actually said "The programming is always the easy part. Designing the features and the interface usually takes 95% of the time."

AstralStorm 5y ago
Your CS teacher never looked at a web browser from the inside, or at other actual big scale software.
- mwcampbell 5y ago
  Still, the teacher is right for most user-facing software that most of us will ever write.
- naasking 5y ago
  I'm not convinced. If designing the features and interface weren't so challenging, why do the user interfaces and other development APIs to web browsers still change 30 years after they were first invented?
- HelloNurse 5y ago
  A web browser might have a higher density of advanced algorithms (than most software, but only because it has unusually extensive, varied and complex requirements (e.g. a number of complex standards like HTML, JavaScript, CSS, WebGL) and unusually high quality standards (foolproof, high performance, standards compliant, secure...),
- JasonFruit 5y ago
  Or maybe they were exaggerating for emphasis, as humans do.