mhotchen

C++: https://github.com/telegramdesktop/tdesktop

This was ten years ago; I might try and dig it up to see if I can get it back, but honestly by now I imagine all hope is lost.

I tried starting a business selling those 30 day WoW subscription cards as I came on to a box of them for fairly cheap. I sold most of them, then one person falsely reported me of fraud and that was it, my paypal account which had all of my profits in it was frozen and I never managed to recover the money. IIRC I had close to £300 and I never found out what happened to the money; I imagine paypal just took it as profit despite every buyer giving me positive feedback up until that point.

I was considering starting a marketplace on Amazon last year as well with a friend, just selling basic Chinese made goods but it sounds like things like this are rampant there too, and honestly I'm seeing a lot of sellers on Amazon lately that are scammers, so I'm beginning to lose faith in Amazon as a consumer as well.

If I'm going to try and make a business from selling goods online I would want to run my own ecommerce shop using shopify or something similar.

SQLite, LMDB and RocksDB are all popular and embedded. They're not really web-centric though so don't get as much exposure on HN and its ilk.

Edit: Sorry if I sound like "that guy," just offering up some names in case people aren't familiar with them.

I've used it as an end-user in an enterprise with LDAP integration. It worked well in that situation and our sysadmin who set it up was happy with it as well.

At home where it's just me using the passwords across a couple of devices I just use KeePass with the database stored on dropbox.

It is different though. When I've broken bones and had to wear a cast it's a novelty so I enjoy the fluttering moment of being the centre of attention. But when it's something that they have to deal with for the rest of their life, the psychological effect will be a bit... different. I can't fully extend (or bend) one of my arms from an accident a few years back, and it took me quite a long time to be accepting of this fact.

Thing is, I've never heard anyone ever complain that not enough people point out that glaring flaw in their anatomy that they've struggled to deal with internally. So I figure it's best to err on the side of politeness and ignore it unless it's relevant or they bring it up themselves.

Maybe he's using a front-end cache like Varnish which is effectively generated static content held in memory.

I've been travelling for a while in areas with slow internet and the best site for me has to be HN. No BS, it just loads and gets out of my way so I can access the content.

I'm in China atm, which is probably an area that Stripe would want to target with both atlas and connect (there's a ton of marketplace/ecommerce sellers based here, and a lot of tech innovation), and both those sites take a stupid amount of time to load.

That animation also destroys my mediocre laptop.

The pages look nice and are rich in content, but those animations and all the superfluous fonts and stuff cause them to be almost unusable if you're not on reasonably new hardware with a reasonably fast internet connection.

> the rule would be no ternary operators

Why not "no nested ternary operators"?

> You don't need to wrap if conditions unless you have a multi-line body

Why not "keep unwrapped if conditions on a single line"?

> Early returns simplify short circuiting logic unless your function becomes too long

Why not "keep functions short"?

> Using a variable as a conditional in javascript to test against undefined works well unless the value can be falsy

Why not "only use conditionals on boolean values"?

I'm not saying your rules are right or wrong, I actually follow a couple of them myself, but your wording implies that other people are simply not following rules, or their rules have a lot of nuances and special cases, but the reality is more likely that their rules are different.

Ultimately we all make different connections and form different patterns in our head. As long as a team can agree on a code style, within a few months everyone starts developing the same cognitive patterns.

Despite being in the man page, the flag --version didn't work for me on Ubuntu 16.04 (various different installations):

    $ init --version
    init: unrecognised option '--version'

systemd --version works though:

    $ systemd --version
    systemd 229

Many of the programmers I have worked with actually love complexity, despite trying to convince others (and most likely themselves) that they hate it.

Advice tends to be cherrypicked to suit an agenda they already have (with your example on microservices, the vast amount of resources saying they're very difficult, should be driven by a monolith first approach, and solve a specific set of problems is largely brushed under the rug).

I think because our industry moves so fast there's a fear of becoming irrelevant. Ironically companies are so scared of not being able to employ developers that they're also onboard with complicating their platform in the name of hiring and retention. I think this is down to the sad truth that most developer roles offer very little challenge outside of learning a new stack.

He's started work on his next book[0] which looks to be interesting.

[0] http://modern-sql.com/

Yeah good point, you're right. The root user is defined as root@localhost, not root@%.

On Ubuntu specifically if you do the quiet option (for example as part of an automated script) then it will leave it blank. Even with the prompt it says it's optional but encouraged.

I wouldn't call it a bastion of security but MySQL typically installs with a root user with no password. So how do they not have the same level of exposed data? By default only local connections are allowed. If Mongo had the same pattern then this whole calamity could have been avoided whilst still allowing the ease of setting up on local environments.

I use JSON API which allows for "compound documents" instead of deeply nested results[1]. I would say it's well expressed, and it doesn't violate any of the principles of REST.

[1] http://jsonapi.org/format/#document-compound-documents

Well just take the example on their page for example. With ESI you would fire off to a server process that has to then go seek a user, then build up some HTML using a templating language in python or whatever you're using and return it to varnish.

With edgestash it looks like varnish holds the template, compiles it, caches it, then injects values in to it from JSON, which is easier for the server to generate and easier for varnish to inject the values from.

For HTML that's very dynamic based on user data ESI isn't an ideal solution, you either end up with a ton of includes (and thus a ton of requests), or you end up basically having only the shell of a web page cached by varnish. With edgecache you would have a single request (or a handful) returning all the data as JSON, and varnish would have a cache of basically the entire page to inject the values in to. Your server-side code doesn't have to deal with HTML at all, it just provides data. I'd say it's less competitive with ESI and more closely competing with single page apps, but you're moving the load back on to your server so clients aren't downloading javascript for injecting data in to HTML templates.

It doesn't confirm that China is 'rural at its core' at all. When more than half the world lives in urban centers then being in the bottom half doesn't mean anything. If over half a country lives in urban centers then you simply can't call the country 'rural at its core'. It has a massive rural population, but it isn't 'rural at its core'.

To make an edit: I think we're arguing over semantics of terms at this point. I don't think we're actually disagreeing about anything important. I never asked for China to be called urbanized (although I would use that term if forced to use one or the other), just that calling it 'rural at its core' doesn't hold up anymore. If you still think that statement holds true, then I'm sorry that we're going to have different definitions of that term.

It's still wrong to call a country with over half its population in cities "rural at its core". It isn't transitioning from a 'rural era' either. It's more urbanized than Slovakia, Romania, Slovenia, and several other developed countries[1].

https://en.wikipedia.org/wiki/Urbanization_by_country

China's urban population is over 740 million[1]. For perspective the USA is almost 260 million[2]. I don't think your assumption holds up in the modern world. Maybe 20 years ago.

https://www.quandl.com/data/WORLDBANK/CHN_SP_URB_TOTL-China-...

https://www.quandl.com/data/WORLDBANK/USA_SP_URB_TOTL-United...

I looked at it a while ago using OpenSSH's AuthorizedKeysCommand feature and found Phabricator's implementation for vcs over SSH to be the most understandable thing I could find.

https://github.com/phacility/phabricator/blob/master/resourc...

https://github.com/phacility/phabricator/blob/master/resourc...

https://github.com/phacility/phabricator/blob/master/scripts...

> A job is just a deal. It is a deal between you and a company to exchange labor for money (and other things you value).

This came naturally when I became a contractor. Rather than having a salary based on market rates, I was offering the services of my own company that has N value in a B2B deal. It does sound like an abstract point, but it completely changed the conversation at the table.

They wouldn't ask questions or admit that they're struggling with something. I saw a lot of this in the interviews as well, you would ask a question like "do you know what X is" and they would say yes, but then sit in silence. So you probe "well what is it?" and they would go "I'm not completely sure" or just try to make something up. They would sometimes sit for days doing nothing because they didn't understand the ticket.

Another was their definition of done. They would finish a ticket and mark it as resolved as soon as the functionality is partially working. I think because QA is enormously cheap in India they were used to handing things off to QA as soon as possible to save their own time. We didn't have a QA department so that was quite problematic. I started having to include all the edge cases I could think of in the ticket.

I don't think it's necessarily wrong, it was just different, different levels of politeness and views on managing their time. But it was these differences that made things more difficult for everyone involved than I expected. They probably had a lot of issues with my management style as well, although they were too polite to say anything :)

Yeah these definitely weren't top tier developers. Even so I was happy with the quality of the code on the two we retained, it was everything that goes around it that I struggled with. For example they wouldn't ask questions or admit that they're struggling with something. I saw a lot of this in the interviews as well, you would ask a question like "do you know what X is" and they would say yes, but then sit in silence. So you probe "well what is it?" and they would go "I'm not completely sure" or just try to make something up.

I definitely agree with you though. We interviewed one person that was exceptionally good: very experienced, good comms, ticked all the boxes. His salary expectation was around a junior dev salary in the UK, which unfortunately was too high for management who had set a budget per developer, rather than thinking it was worth hiring him and one other instead of four lukewarm devs.

I set up an offshore team of four in India some years back. Two of the developers ended up being lackluster and let go, but two of them continued on as they were fairly decent. Even so the cultural difference was significant and it was difficult to manage them. I don't think it was their fault, they just had a very different views on what they considered was a completed task, how they went about asking for further requirements, etc. Whilst it was worth having them, there was a surprising and hidden overhead in cost for the cultural impact, as well as timezone issues.

Later in my career I worked with a team from Hong Kong as well, the cultural gap was less significant and they were able to work well with the management style given. We still had timezone issues (moreso since I'm from the UK which is further from HK than from India), but because they interpreted tickets in the same way and had similar views on what the definition of done was things were far more harmonious.

Communication is a huge factor in remote teams, and whilst there are lots of tools to aid it, communication styles across cultures can be very different which can cause a lot of friction.

My first dev job was like this as well, also in a tiny company hiring at a slow rate (I was the only person hired in my time there, and also the only employee). I think that this sort of thing worked for the company I was employed at because the work wasn't very technically challenging so I was able to get on with things quickly and it became more about cultural fit.

It's interesting that the parent is suggesting this for when you have a lot of experience rather than when you have none.

Given the number of people I've interviewed over the years who have 10 years experience and look very strong on their CV, but still struggle with our basic "coding challenge" (on par with FizzBuzz but more aligned with what our company was doing), even before we get to the real interviewing (with another alarmingly high dropout at this point as well), I can't see hiring for a trial being an effective strategy. We would be sinking way too much cost and effort in to it.

It may also result in poor hiring choices because one person's ticket/feature/whatever may have hidden challenges, and another person's might be easier than initially assumed. There's now more randomness involved in what's an already too random process.

Maybe interviews should be a bit less involved, and companies should be more willing to take advantage of the probation period (and employees too, I've seen a handful pass their probation and regret it).

There's also these:

- https://runc.io/

- https://linuxcontainers.org/

And I'm not sure if they're the same thing, compatible, or what. I'm going to let someone else pick the winner for me. I'll come back to containers in like a year or so and see what the lowdown is.

Hey thanks for this, I finally got around to watching it. That's a very interesting way of handling it.

Yeah that makes a lot of sense. I think points two and three would be beneficial to the article, because point one by itself could be said of a lot of things (eg. large methods and classes, or deeply nested and complex algorithms).

Thanks for your input!

Coming from an OO background the idea of hard-coding dependencies makes my palms sweat a bit. Your example is pretty simple and I agree with it but for objects/packages that are "reaching out" to the wider system rather than staying in their bounds do you not think this principle could create a loosely cohesive system? I would say that dependency injection isn't just about swapping behaviour, but it's about cohesion and bounded contexts and all that stuff that makes systems easier to reason about.