fdw

Thanks, this is neat. I love to see where the people are that liked my software so much they starred it. Makes it a bit more real that they're actual people and that all the time I spent on it is worth it.

So far, I've been using https://thepirat000.github.io/StargazersMap/index.html so far, which has a more... basic interface, but also seems a bit more detailed with usernames.

I agree that the Bitwarden cli is awful. You have to log in, and store the token it gives you manually so that it knows you're logged in.

However, I found https://github.com/doy/rbw , and alternative OSS cli written in Rust, and it's exactly what I wanted. (Disclaimer: I liked it so much I wrote a rofi integration for it.)

That depends a bit on whether the language you want to support is already supported by your platform (Alexa, say). If it is, it can be as easy as gettext. It can also be a bit harder because you want to take cultural behavior for conversations into account.

If your language isn't supported by the platform, you're just out of luck. The best you can do is request your platform to translate it, but that is - like vages described - a lot of work and will take time.

Thanks, that's a very kind offer :)

Consider it just some basic help on your journey.

Quick heads-up: There are some grammar problems on your landing page (e.g. "it can be send out to multiple email address like mail group." should be "it can be sent out to multiple email addresses like a mail group."), and there's "superful", which I'm not sure I understand ;)

Good luck!

I'm sorry, I'm not sure, I totally understand your argumentation. You seem to be against vague rules ("My experience is that vague rules are both a recipe for corruption [...]"), with which I agree. That's why I want a CoC, so that the rules are open, known and overall transparent.

However, I'm afraid I fail to see why avoiding vague rules means that there should be no CoC at all. Isn't having no written/open rules the vaguest of all? Even if there are rules that only the moderators can see, how is that an improvement for the participants? They can't know what is acceptable, so neither can the accused argue against an unfair response, nor can a potential victim demand enforcement.

And why not have more concrete rules? Surely, they cannot be complete and there will necessarily always be room for intepretation, but I think it is better the more concrete the rules are.

> And unreasonable people don't care about lines and rules.

I agree with this statement. Having or not having a CoC will not change their behavior, nor should it change your response. But the response to your response can differ: If you've been transparent from the start about your rules, there's less room to complain about you enforcing your rules. If you had no CoC beforehand, there will be some parts of the audience asking if that was really fair. And this behavior doesn't even have to be malicious, just that their line is somewhere else, and so they don't understand your arbitrary enforcement. With clear and transparent rules, they may not agree, but it's clear where the line is. We both think (at least, that's what I gather from your comment) that some rule is necessary, but I'm for being open about it and you want to keep them vague. I think it's easier for everybody to be transparent here, because you can decide beforehand if you agree to these rules. If they're too vague, I'm just hoping that, if push comes to shove, we see the world similarly.

And, again, having a CoC also signals that there is a line. Without it, who's to know that there will be behavior that you don't accept and what it looks like. Maybe you're fine with sexist comments, but not with racism. If I'm vulnerable, why should I gamble that your views are similar to mine? I'd rather not visit your conference if you can't make the rules clear.

While I agree that a CoC should be no surprise to anyone with common sense, it still makes sense to me to have them:

First, there are people without common sense. Sooner or later someone will not adhere to the unwritten rules and ask "Who's going to stop me?". Even if you can eject/ban them, it will be quite a mess, as you now seem to enforce completely intransparent and artificial rules. People will (rightly) ask you to state the rules before you enforce them. Even if your rules are completely obvious to you and all the people in your peer group, they won't be to everyone.

On the other hand, a CoC signals to potential participants that you take these things seriously. Look at it from the point of view of someone who is used to sexist/racist/otherwise discriminating comments: If you see that a conference has a CoC, that means that they know of your problem and are prepared to combat it. This is more a more inviting conference and it will put you more at ease, because you can feel safer. Without a CoC, people will not attend because they're just tired of this.

So, yes, CoC should be unnecessary because we all know how to behave. Ideally, their content is suprising to no one. But experience shows that not everybody does, or that they in good faith behave in ways that are not acceptable to other people. With a CoC, you make it clear beforehand that "these are the rules", so everyone's on the same page, and you show that you mean it.

> but from within the rendering application.

I'm not sure if you imply that the emoji glyphs are not from a font, because they usually are. To display emojis well, you should have your normal font setup, plus one font for emojis (like [Noto-Emoji]. All desktop applications I use display these glyphs and don't interfere with it. The only example of something overriding your selected font is Slack, which uses small images if it knows the emoji. At least, that is true on my Linux. What Windows does, I have no idea.

[Noto-Emoji]: https://www.google.com/get/noto/help/emoji/

> Javascript is a great language for building UIs

I disagree. It is easy to build something presentable with HTML and browsers, and there have been many JS frameworks that lower the barrier. However, that is not because JS is a good language for it; it is because JS is the only language available in that environment.

In fact, there are at least two other languages that transpile to JS, because you need JS to be able to run in a browser. But JS the language is not good enough, so you want two write your code in something else.

Building a UI in a completely different language, without a browser, is definitely harder, but you might have several advantages in the other, non-UI parts.

Some plugins that saved me lots of typing with zsh:

https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/histo... looks through your history and only shows entries that started with the same characters that you already typed. Similar to Ctrl-R with fzf, but still similar enough that I use both.

https://github.com/zsh-users/zsh-autosuggestions also looks through your history for commands with the same start, but it will automatically suggest them for you to use. If you often use the same commands, this saves quite some typing. For bonus points, I hooked it up so that Ctrl-Return will execute the suggestion.

https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/per-d... To make the first two even more powerful, I split my history based on the directory I'm in. This means that it's only suggesting me commands I entered before in this directory.

The advantage of autojump - at least for me - is that it doesn't depend on the shell, as it is implemented in Python. This makes it possible to read and write the data elsewhere, too, independent of your shell.

For example, I integrated it into ranger (see my history, I don't want to spam HN with this project).

Instead of z, I use https://github.com/wting/autojump, which is written in Python. This has the benefit that you can call it from outside the shell, too.

Since I also love ranger as a file manager, I wrote my own integration of both: https://github.com/fdw/ranger-autojump . It remembers where I went in ranger, and I can also call autojump in ranger.

Some time ago, I would have agreed with you about Adapters, Factories and so on. But now, I'm not so sure.

My team inherited a code base that wasn't really legacy - maybe two years old - with a very simple business logic: Collect data from one REST service, save it in a "cache" database and answer to requests from another one. Seems completely simple, and the code wasn't awful, either. However, there was no abstraction, no layers, nothing: The REST controllers knew exactly what the DB looked like and contained a large part of the collection logic. There was a client for the collection, but it was very low level and exposed everything. Additional domain logic was smeared over five to ten levels of hierarchy.

In the end, each apparantely simple feature we had to add took days instead of hours because we had to touch so much code. The principle of locality was completely absent. In the end, we rewrote large parts of it so that you don't have to change the REST controller anymore if the DB schema changes.

My personal lesson was that you should always have some abstraction, even if the service's task is so simple. Things will change, and you must be prepared for that. If every part of your code knows all the other parts, you're doing it wrong. Have clear interfaces and boundaries (and models) so that changes can be localized. Of course, that doesn't mean that you should implement something like: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... .

> The Color of Magic - Terry Pratchett (Kinda interesting, but rather odd)

This is the first book on Pratchett's Discworld. It definitely has a different tone than his later works. If you've not totally annoyed by it, or if you'd like to read fantasy which strongly mirrors our world, with a dry and playful humour, I'd recommend reading some later ones. They are quite independent of one another, so that you don't have to read them in order (although there's several sets with the same protagonists).

Personally, I'd always recommend Going Postal, maybe Night Watch (a bit of back story could help but is not necessary), or Monstrous Regiment.

Ah, thanks for clearing up my misunderstanding. That makes it even more interesting!

Thanks, I was wondering if you can parse all comments for a link to Amazon or something (but even that probably wouldn't get the recommendations without links).

At least for me, OneLink doesn't work. Apparently you need to be in the US, Canada or UK; the other countries aren't supported so far. Pity.

Thanks, that looks quite interesting. I have already found a book I might like.

> I'm adding recommendations and products daily. Do you add the recommendations manually or do you use a crawler/API to copy the comment? How automatic is it?

Finally, I have two suggestions: You're only selling to people in the US. Maybe you could also add links to other Amazon domains (or use a service like geni.us)?

And how about linking back to the comment thread? Sometimes, a comment only makes sense in its context, and I couldn't find a link back.

I don't think you'll care to read or think about this reply, but others might, and HN is for me also about open-minded discussion.

I don't pay through my nose for healthcare. According to a quick Google search, it seems to be about what the average US resident pays (while I'm above average in income for my country). For that price, I don't ever have to worry about going to a doctor or hospital. I'm feeling sick - I go to the doctor. I have a toothache - I go to the doctor. I think I broke my finger - I go to the hospital, wait a few hours, and learn that everything is alright. I can't imagine having to wonder if the visit is really necessary, because I need the money. I don't want to have to choose between health and money. For me, this is comfort.

Additionally, I have friends with chronic diseases. They cannot emigrate to the USA, because they couldn't pay the medicine. That doesn't sound like a first-world country to me, where you cannot afford to treat your sickness, even though you've got skills and a paying job. That sounds like a bad dystopian movie.

I have now tried several terminals, but most lack one feature: I use zsh's [autocompletion plugin], and I'd like to call the suggestion with Ctrl+Enter. On the other hand, sometimes I want to execute only what I typed in, with Enter. However, almost all terminals cannot differentiate between Enter and Ctrl+Enter. The one that could is Terminator, but that depends on gconf and I don't need the tiling. Sakura, urxvt and Alacritty cannot. Does anybody have a suggestion for me, or a better mapping?

[autocompletion plugin] https://github.com/zsh-users/zsh-autosuggestions

> How do you feel about potential solutions I have mentioned in the post, e.g. exposing the candidate to a project during the on-site for 3 or 4 hours?

It's certainly another interesting idea, but from the top of my head, I find several drawbacks: The first is NDAs, as not all code may be exposed to non-employees. Secondly, it will disrupt your team for a bit, because at least one developer should be available at all times and can't really join discussions or go into deep focus time. Finally, and most importantly, I think it's impossible for such an interview to have internal consistency: Every candidate will probably solve a different problem (or do you keep a bug open just for interviews?) in a very different social situation. If you're more the nervous type, you suddenly have a whole room full of full-blown developers see you sweat. Internal consistency, however, is one of the most important themes in interviews for me. Everyone deservers teh same chance.

> Paying every candidate is an expense, but is it less expensive than hiring the wrong candidate and then needing to fire them? It seems like other comments here have already pointed out that they pay something like 160k annualized salary hourly rate, which seems pretty reasonable.

But is it less expensive than other methods of interviewing? If a classic whiteboard has a slightly worse chance of hiring the wrong person, but has no additional cost, it might still be better, all in all. Additionally, the expense depends on how many you interview for a given position (is there a filter interview beforehand or do you invite every reasonable resume?). A better idea that we sometimes use it to hire uncertain, but hopeful candidates for a paid internship. If they're good, the get a full contract; if not, we haven't lost much. Also, it's an easier decision after several weeks than after four hours. However, we can't do this for everyone.

I'm getting a bit frustrated with the talk about interviews, as we repeat the basic message every now and then, but nothing changes. I feel we all agree that the current status quo is not good, but so far there has not been any good alternative:

- Whiteboards are unnatural. Besides, you don't want to check their knowledge of university-grade algorithms or data structures.

- Problems to take home are an artificial setting - you can't be absolutely sure that they did the work themselves, and you have no idea how the mesh with other people. And you probably get some false negatives because they're stuck and can't ask their colleague.

- On the other hand, if you're using real code from your project, you're just asking for unpaid work. And paying every candidate is a significant expense.

- Using a proxy measure like HackerRank or a Github portfolio excludes people from minorities or who only want a job and not a mission.

- Not doing any coding opens you up for people who can talk, but not code.

Have I missed anything? Is there a good alternative to find the right people? I'd love to improve my company's interviewing process, but sooner or later we always hit one of the mentioned problems.

Yes, it is explicit.

I took your comment to say "You have to allow access to your data if you're using OAuth, because that's how OAuth works", and wanted to argue against that. The OAuth protocol is so complicated because it tries to be safe and secure and so it doesn't force any data disclosure. However, I now see that you probably meant "OAuth forces you to accept these permissions explicitely". In that case, we're hopefully both right :)

No, this is not how OAuth works - OAuth itself is just a protocol to receive authorization from another server [1]. In this case, a third party relies on Facebook to say "This user has logged into Facebook and their ID is foo". OAuth _does not need_ social information or anything else.

Of course, you can allow the authorization server to publish these details, but this is not an inherent part of OAuth. Also, there's OpenID Connect [2] which builds on OAuth and adds just this information in another token: "The ID token resembles the concept of an identity card, in a standard JWT format." (from [2]). However, you can happily use OAuth without ever publishing the user's details.

[1] https://tools.ietf.org/html/rfc6749 [2] https://openid.net/connect/

If I remember correctly, the original GoF book was inspired by patterns in architecture [1], so it's more about naming patterns they have often seen, and not about "if you use these patterns, your code will be better". It's a glossary of sorts, so developers can use the same words for things. This aim is independent of language and paradigma; the authors just happened to see mostly OOP.

However, just like Asdfbla said: People started to use it as a kind of manual and applied the patterns no matter the problem. Again, the problem is more the people than the idea...

[1] https://en.wikipedia.org/wiki/Pattern_(architecture)

It isn't easy, but so far I've had luck with my co-workers. If they were more dogmatic, I think I would see Clean Code more critical too. But as it stands, I still recommend the book to new colleagues, and our culture takes care that we don't follow each "law" to its letter.

While I agree that can devolve into a dogmatic belief system, I also think that that's partly a people problem.

Many of the ideas in Clean Code make code more readable (for example small methods, each containing only one level of abstraction; or good naming). It's on the coders to know how far to take these ideas and when to be pragmatic and say "good enough".

Could you please elaborate that? I still see patterns like Builders, Factories, Singletons and even sometimes a Strategy in Java. Why do you think they are bad? What are the functional alternatives?

I agree that most of the advice is pretty obvious if you reflect on your and other people's behavior. Also, I grew pretty tired of always using a string of anecdotes as support. Sometimes they don't even seem to fit the current chapter.

However, I think the important point of the book is that Carnegie succinctly collects a small number of behaviors that will improve your social life if you apply them. So you might not learn something new in the book, but hopefully it will teach you to focus on these known things instead.

While it is certainly true on some level, I think Carnegie chose not to use "manipulate" for a reason: It's not so much about getting them to do what you want, but to see the issue from all sides and choose a path that is beneficial to you both. He also repeatedly stresses honesty ("honest appreciation"). So even if there is some amount of manipulation, it's still mainly about seeing everybody as a person and working together.