PeterGriffin

Oh I see, Pinboard is so innocent, so pure, that a honest tip about how to reach more people who can find their service useful should be modded into the ground.

I've tainted the Jesus of bookmarks by even implicitly suggesting in my post that they might be writing with the intention to be read. No, I suppose their intention is way more cosmic and godly than such low earthly concerns, how stupid of me.

Aight, aight. I never stop learning when I'm here on HN.

You have totally missed the point of my post, and I guess most of those that modded it.

EDIT: Ok this is starting to get a little weird. What's with the comical negative overreaction to my posts. What exactly did I say to warrant that?

A bit of a lost opportunity, because I've barely heard about Pinboard, and the fact of them celebrating the passage of time since they were found, is extremely trivial. BTW, MySpace recently turned eleven.

When writing posts and news, typically you want the headline to focus on a new feature, a new app, or if it'll be a number, focus on a meaningful number, like number of users, something that could engage those who aren't engaged right now.

Way it is, a birthday party of some company I know little about is someone else's party, and I won't even open the article.

When it comes to basic formatting, symbol naming and high-level code organization, sure.

But computer languages, unlike human languages, are precise. Their intent is clear. And you'll never encounter a case where the Python 3 interpreter hasn't heard of that particular Python 3 keyword you're using.

It's also not an excuse to avoid certain features of a language, when using them leads to a better and simpler solution, just because they're less popular. Programming is not an exercise in popularity.

On the other hand, human language is fuzzy and full of phrases that consist of statements having nothing to do with their meaning. Such as me saying "your argument doesn't hold water".

Human languages also have additional layers entirely separate from the primary meaning of a conversation, such as sending social cues like "how smart am I", "do I like you", "do I fit in this group", and "am I a leader or a follower". Each layer of concern drives a certain way of expression and imitation, none of which occurs (or should occur) when writing computer code.

A better example to compare to programming code would be mathematical notation. As long as you express your intent shortly, using the available mathematical notation, people will be fine, and your intent will be clear.

I've never seen someone ask in a math forum if their formula is more Mathematic one way, or another way.

I don't believe it, because I use SQL every day, and I need to tell it which rows to lock when reading, whether to read them in share mode or fully, sometimes I need to help it figure out which indexes to use (of course I also have to manually set up the indexes too), when doing transactions I need to tell it how exactly to isolate the transaction, and I need to be very careful how I order my queries in order to avoid deadlocks.

SQL is declarative only when you don't care about data integrity and performance.

Maybe a bit better example for this kind of behavior are compilers. They're pretty "declarative" these days. You write what code you want to compile, and the compiler will pass it through a thousand transformation stages, deciding which trick to apply at every instruction, which code isn't really needed and so on.

Of course, then you also need to deal with compilers getting it wrong too, so you start tweaking your code with special words like "volatile" and "restricted", mess with compiler options, and sometimes even disassemble code to see why turning the "fast" options makes your code slow. But in general, high quality compilers do this dance way better than SQL.

So what's the moral here? Two things.

First, calling something "declarative" doesn't really mean anything. It means the language is built on a very thick abstraction that lets the computer do more work than usual, so you can do less work.

Second, thick abstractions are leaky. Works for basic cases, past that you'll still end up doing a lot of work, but now you have to fight your computer while doing it, as well.

The Z3 Theorem Prover is an interesting toy, but I wouldn't trust it to do anything right in the real world. Much like most Microsoft Research projects, unfortunately.

So, we're all very very angry and we'll... do what about it?

Nothing.

This is hardly the first time this happens. There are about half a dozen cases of this kind in mainstream media every year. Plenty more go unreported. Nothing changes, because everyone feels comfortable being outraged talking about it, but they wouldn't touch the problem with a 20 foot pole when it comes to acting about it.

http://en.wikipedia.org/wiki/No_true_Scotsman

Don't ask what's "more Pythonic" or "less Pythonic", Python is not a cult, it's a very practical scripting language. Ask for benefits and weaknesses of a given approach in given circumstances.

You seem so passionate about this, it hurts to break your heart.

When you set your text to be bold, that's a separate font, made by a human hand.

Browsers have a fake bold look when the font is missing, but it's not a look you want on your site. They just, well... smudge it to the right. For Emoji the fake bold look is disabled, because bold or italic emoji is just non-sense on the face of it, so they don't support weight settings.

Also, you can't set the color of Windows Emoji via CSS. They're already colored.

It's not "the future of color fonts", it's just the present of emoji in Windows. And I really don't like the way they did this.

The technical approach is smart, but lazy, and the resulting emoji look bland and lack definition. No wonder, since this approach doesn't support the way artists work. It's not SVG, it's not PostScript, it's not a bitmap, it's just a glyph sandwich. No opacity, no gradients, no effects. It must be a pain to split your pictures in layers so they can be in a font like that.

As far as using this for text... the novelty of such effects faded out sometime in the 90s when Word Art was all the rage among design-blind office workers.

In the modern world of Unicode, it's even less likely we'll start making fonts with hardcoded layers of cheesy effects when you need to cover a good range of international characters, weights, cursive, hints, kern pairs, ligatures, alternate versions and so on.

If you think about it, this falls firmly into the "symbolic gestures" category.

They had nothing to gain or lose from making this into a political statement, so they invited them.

You learn about responsibility and authority when there is something to gain or lose.

Thank you for showing us. I have two pieces of feedback.

1) The score isn't most important. The headline is. This is why the headline is in black, and the score is in gray. We don't come here to compare news importance, the site already does this for us by sorting. We come to read news. And having a small pale gray score replaced by a big attention-drawing glowing orange square goes against where the focus should be.

2) I do part time design and understand the temptation to style your presentation so it enhances your concept, like add perspective, drop shadows, and so on. My team does this when presenting business card designs to clients, because the actual graphic looks so simple and boring on a monitor, the client won't "get it", if we'd show it as is.

But a website isn't a 3D slab floating in space, so in this case the styling is a distraction from your presentation, not an enhancement. Keep it simple, when simple works.

I'm an idiot, but I'm willing to believe there are still people out there who love what they do, and would stand by it, even if Corporation X comes knocking on the door with a pot of gold.

I'd rather cheer for them and be disappointed, than dismiss them in advance and live my life perceiving the world through a cynical lens.

Huh. I didn't know I can write so dramatically. You catch my drift, though.

Neither. I'm not sure how I can help you, maybe try reading it slower.

No, why would this be something to try to avoid? Sexism and racism is a kind of cultural trait, I hope you realize that.

A culture may be selective on very different criteria. It can easily be blind to gender, race, age, religion, nation and many more, yet have certain very specific values. And letting people in who have the opposite values are toxic to that culture.

You can't have a culture that's "open to everything". It means you have no culture, you just adopt the zeitgeist unmodified. Everything goes. If this was the goal, this thread wouldn't exist.

I'm sorry, but I'm starting to get a bit sick of Hacker Schools constant whining about rules.

If you want to encourage a specific culture you do this by starting with a small set of people who have this culture in their bones, then growing slowly and assimilating more people into that culture, addressing deviations swiftly and letting people get back to their work afterwards, without skipping a beat.

Not by writing manuals, and then stressing everyone with looooong, reaaaaally long and exhausting "we need to talk" style posts, where we hold hands, talk about how it's so difficult to open your mouth and say something that's not offensive, and how we're far from perfect, and in fact, we're all sinners.

It's not that the intent is wrong. But this way of going about it is so extremely taxing on everybody, creating an atmosphere where everything people say is judged on the "-isms" scale.

It means when you talk, you're terrified of what you're saying.

When you listen, you listen for someone to say something so you can point your finger at them.

Well, as usual most arguments revolve around misunderstanding terms, and not substance, heh. I was too harsh in few places, as well. Sorry.

I really don't feel there's a need for us to separate "native" database transactions and app-level transactions. They're both implemented using the same underlying principles. But I've noticed people see a huge difference between them in blog posts, articles and conversations.

I think it reveals a kind of thinking that database transactions look like magic, while those we roll ourselves... we see all the ugly parts of the sausage factory there, and it no longer feels as "atomic" or magical as what databases expose as an encapsulated abstraction.

The reasons the graph is centered around 30s with a halo in 20s, 40s and 50s is the same reason the graph lacks "under 10" and "over 80".

It's just how humans work. We get born, have a period of growing up, gaining experience, then a productive period with big bold dreams, then settling, retirement and death.

I guess without the finger pointing the data would be so boring that it wouldn't warrant an article, so here we go.

It's an option, and it sure is neater to those creating the library, but it's much less neater to those using it. Not everyone compiles a PHPDoc for themselves when downloading a library, so then all classes form a nice big pile at the root namespace.

In terms of neatness and ease of use, I choose like I'd choose how to optimize code - I focus on the parts that get most use. Users of a library are hopefully way more than its maintainers, so it feels like it's worth slightly inconveniencing the maintainers in order to have an instantly clear public interface.

"In practice, it makes much more sense to allow the system to enter certain inconsistent states and then remediate them. Out of an ingredient? Refund the money. Can't pay? Pull the drink out of the queue, or just write it off. This can involve some cost, but less cost than than the throughput you'd lose by enforcing consistency."

I don't know what practice you're referring to, but unlike commodity coffee drinks paid for in cash 1) CC refunds are not free, and they're not cheap in volume at all if you intend to do it casually during normal operation 2) not all goods are standardized and available in large quantities.

Your examples are all over the place. Ticketmaster is an example of a reservation system similar to one I was trying to give an example of (two step commit). A resource is locked, the lock is held for a short period while collecting answers from the other subsystems (in this case, payment gateway), and then a final commit is issued (or a rollback is issued).

Airline overselling isn't done because it was some microservice design dogma about how great inconsistent state is, but because every seat costs the airline a fortune if left empty, and a certain % of passengers cancel or reschedule their tickets, and the airline is trying to arrive at an airplane with as few empty seats as possible. Having your tickets canceled is certainly not something that happens "often", thank god, but it does happen as a result of that tradeoff.

But if I reserve and buy my seats online for a cinema movie, and then I go with company and get handed my money back because "it's practical", I'll make a scene. And so no one implements cinema ticket reservation this way.

For bank overdrafting, it's a very special case - your money is a number in a computer, and the bank owns that computer. They make the rules... so they did. It's easy to mess around with numbers like that. Bank account overdrafting is probably the biggest exception of them all as no physical products and services are involved. No one's going to have their lawn un-mowed because the bank allowed your account to overdraft.

The only common thing between your examples is that they're driven by business concerns, not some ivory tower concern about service design. And this is why they're so different, and reserving resources is and will remain a common practice for many, as long as the business logic calls for it. There's nothing wrong about it.

At some point in life we become so busy with something else that we stop keeping up to date with the latest trends. Suddenly we realize everything has changed and has become foreign and complicated. We feel stupid; incapable of catching up. We feel old.

But listen, it's crucial to ignore this fear, because it's wrong. We don't really lose our ability to learn way until retirement (and for the lucky ones, even past it).

When you decide to stop looking back, and decide to bravely dive into the big unknown, you realize "you still got it".

Been there, done that. I still got it ;)

Thanks.

And yet, nothing you said really rejects my made up explanation, even more, it supports it (the visual center stops sending information as it lacks input, and synchronization attempts begin).

That's often not practical. Say you're a shop front.

If you have a goods purchase service and a goods delivery service, you want to reserve the good (limited quantity) and reserve a time slot for transport (limited number of deliveries a day) before you charge the customer, and make the "commit".

And if you'd merge two separate companies into one uber-service, you've just created more problems than you've solved.

The post talks about synchronous communication increasing temporal coupling.

There's nothing in sending a request and getting a response that's increasing coupling in a traditional sense, and often there's no much of an alternative anyway, if you want donuts, you'll have to request donuts, and then receive donuts.

While I dislike shoving HTTP everywhere for many reasons (reminds me of XML abuse), HTTP is not synchronous, nor asynchronous. It's a protocol sent over a socket. Synchronicity is not the domain of HTTP at all. It's up to the application how it does it.

Additionally, the response can always be a blank acknowledgement of the received request. There are very few cases where you just want to go forward blindly without even receiving an ACK about your request at some level (or alternatively, an error), because sometimes things fail.

Well, it's a U shaped slope, because at some point you become less productive, not more productive as you add time.

So it's about finding one's balance. If someone's balance is 16 hours a week, so be it. I just find it a bit unlikely though.

Oh I see.

I wish PHP had visibility for classes, oh well.

Do you know what I do, I put everything that's not meant to be used by "the public" in sub-namespace "Internal". So, say "Vendor\Project\..." for public classes and "Vendor\Project\Internal\..." for volatile internal matters.

This means there's no confusion about what people should use, and what's just the guts of the system they shouldn't mess with.

The point of a microservice is you can build it on anything, and change what you built it on over time, without changing its interface.

As for your concerns... you know how every time some good idea pops up people have to ruin it by pushing it to ridiculous extremes? Case in point, microservices.

You don't have to make things so modular that you give up SQL, transactions, or anything. With experience you'll naturally start finding where the domain of each microservice falls, and coordinating between them won't be a problem.

I strongly disagree with the poster who said that having joins means it's not a microservice anymore. That's non-sense. A microservice is defined by what it does, not how it does it.

Even the simplest service might be managing several entities that are in some kind of relationship. If the entities in one service are not in strong relationship with one another, it's a sign you can split them in two services. But if two microservices talk to each other so extensively, that the service boundary is becoming a bottleneck, it's a sign that they should be one service.

Do not break down a service into several services, just because it manages 2-3 entities. That's counterproductive, and it'll be the topic of DHH's upcoming blogpost "Why microservices suck" sometime in 2017.

I didn't have time to review the project in detail, but one thing that made an impression on me is having a registry in there.

Many projects make the same mistake. The registry/service locator/DI container or whatever flavor you prefer should be an application concern.

Applications should create this for themselves, and not every library having its own registry just for instances of its own classes.

Similarly you have factories and builders which wrap a constructor and don't add or change anything. You can remove some of that code and focus on the essence of your library. This way it might gain more supporters and contributors.

I'm not sure it's bad to feel guilty about this. I'm more interested how people who don't feel guilty see life. I mean surely at some point having aimless fun starts looking a bit like wasted time in someone's life, no?

We live to give our tiny contribution to humanity, and we do it by creating something through work. That also brings joy, and we do it to help each other (deviations notwithstanding). But it's a meaningful joy.

If I'd work 16 hours a week all my life, I'd have some serious regrets on my death bed.

I'm very happy to see people working 16-25 hour work weeks, and it's probably very good for their personal life.

Just one question, don't you feel guilty going like that? I'd feel guilty, as if life gave me this time to get as much work done as I can, and I just don't.

I know, I know, weird question. But I'm serious.

"Counter-intuitively, Koubeissi's team found that the woman's loss of consciousness was associated with increased synchrony of electrical activity, or brainwaves, in the frontal and parietal regions of the brain that participate in conscious awareness. Although different areas of the brain are thought to synchronise activity to bind different aspects of an experience together, too much synchronisation seems to be bad. The brain can't distinguish one aspect from another, stopping a cohesive experience emerging."

Right, counter-intuitively... As long as we'll be making up reasons based on that piece of data, how about this:

Global synchrony occurs when a brain is recovering from an unknown or detected bad state, and all major parts of the brain say "HLO" to each other to notify for their existence, proper operation and to establish connection. So it's not that it's bad to be synchronous, but the lack of information from critical parts of the brain causes it to repeatedly reboot in order to recover from a bad state forced by electric rods in the brain.

Hey, I'm a scientist!

Seriously though, why aren't we thinking about what the implications of our experimental data would be on a distributed computing system, which our brain is, instead of giving silly "it's like the key in a car" explanations, assigning causality randomly and without merit?