ShellfishMeme

> as the difficulty and most of the work in a CMS product comes from a front-end (or architectural match, really) that end users can meaningfully interact with and set up dynamic sites, redactional workflows, dynamic user content, theming, analytics+banners, asset management/pipelines, etc., etc. with

Sounds to me like you already made a good case for why those products exist.

Sure, you could also call HTML structured content, but using HTML for expressing the semantics of the content instead of the presentation has always been a bit of a pain. Plus you wouldn't really want to use HTML as a format to share this kind of data with for example mobile applications.

You could use XML, but I'd say that's basically the same as JSON with a fixed schema but with more angle brackets, which is pretty much what those headless CMSs return.

Then on top you need the devs to build the server, and to maintain the DB, to add a querying API, to add SDKs and tooling that enable smooth integrations with the new API, the workflows on top of the pure content, a UI that is intuitive to the people maintaining the content, security audits, scalability for when more parts of the company want to use your tooling etc etc.

Following your reasoning you could also say "Payment provider" is a marketing term for something that is just a DB that needs to sync with some banking APIs and AWS is just APIs in front of some DBs and VMs and analytics solutions are just a JS SDK on top of some DB.

Fundamentally everything we build is just some kind of frontend or abstraction on top of a DB. I don't see how that makes it in any way pointless.

Because the web is moving away from pure content or shop pages to more holistic interactive experiences where you need to integrate content into complex flows that are more application than website. Plus you might want to reuse said content on mobile apps too. There it really pays off to have your content separated as structured data that you can query for.

But is it really true that so many companies create too small services? I admit I haven’t seen too many architectures from the inside but from my experience the problem is usually the opposite: adding more and more things to a monolith that already has serious complexity and scalability issues because it’s the convenient place and is faster to develop. Most of the times I heard about the nano services problem was from articles warning of using services and encouraging monoliths instead.

I completely agree. Often I don't proceed because the point I wanted to make is just not properly defendable at that point. But the ideas written down in the process don't disappear and at the same time I got a better appreciation of the other side's point of view. I'd rather hold on to those ideas and evolve them further than to get too attached and be forced into a situation where I eventually defend my opinions because I moved myself into a position where I feel like this is a deep personal belief rather than a well defined objective-ish argument I tried to make.

I always have to think about that one when I had just been spending 20 minutes trying to formulate an elaborate response to someone's comment, just to proceed to sigh and close the thing without posting it. Probably most of the time it was for the better too.

It's not unusual to have a whole office full of screens and no PC anywhere in sight. Everyone just uses laptops nowadays, which many people take home after work. Then all you have left is desks and screens, and maybe some power adapters.

We usually start out with a non working version, using `var` and just returning `i` from the function and then ask what that would print out and why.

I agree. We always put the little 'for loop that creates a list of functions that spit out the current number of the iteration' exercise first in all of our interviews. Generally, when people solved that one fast, they also did well in the rest of the interview and if they struggled there, they also had a hard time coming up with an elegant solution for most of the other tasks.

What I also like about it is that a closure isn't the only way to solve it. You can use `let` for example to make sure the variables are block scoped, or use `bind` to partially apply a function with the number.

So in the end it's a conceptually very simple exercise that can give you a very good insight into how much the candidate knows about how JS actually works.

I feel like it's undignified because it sounds to me like saying "You can have money, but since you are poor and don't know how to handle it, we give it to you in small daily portions so you don't waste it all at once.". Like parents do with their young kids.

If it's basic income, then you should be free to choose how and when to use it.

For your example about forgotten payments, the result would be that you did not pay, so potentially you may lose your insurance, or you receive a fine or something worse. That's a decision you should be able to make yourself.

If you don't have control over your own money, that's not very dignified.

If you get all your money at once you can always have a buffer for these unexpected things. You also have more freedom to waste it all at once, but I don't believe most poor families are really that wasteful. It's just hard to get by. If you get your monthly check divided up, you can't first resolve the situation and then figure out how to deal with it financially. You have to wait. That might be the difference between making it to a job interview or not, or buying medicine for your kid when it needs it.

If you start coming up with extra cases for when it's urgent and you can get a bigger payout, you're again complicating the system and adding extra bureaucracy where part of the idea is that the simplicity of the system compared to classic welfare systems is what makes it more affordable and allows to give bigger monthly payouts.

I'm not sure how that is relevant at all. We're talking about how a BI system could work and whether it could be a good idea to split the money in tiny daily chunks. I stated that I believe that is a bad idea because I believe it's generally harder to put aside a dollar a day than $30 a month at the beginning of the month. So far I haven't heard any counter argument, just "How would that be worse than what we have now".

Plus that question has so many answers depending on which country you live in. I can tell you for example that in my country you are expected to save part of your welfare money for those cases, which does not necessarily work very well since it's often not enough money to really save it.

This is about the tiny daily portions of money, not about BI.

It's hard to make long term plans with that, because instead of putting aside $100 at the beginning of the month, now you need to save $3 a day. With amounts that small, it's easy to accidentally overspend.

Plus sometimes sudden unexpected costs happen, and you cannot wait another week to slowly save up for it, you need that money now.

Not all poor people are poor because they're drug addicts that cannot handle money. Poverty is hard to escape. I'd rather not humiliate these people any further and make it even harder for them to lead a dignified life just because some people might waste their money in the first week.

What if your washing machine breaks or your kids need new clothes or your car needs gas?

It seems to me with this approach people would be stuck in perpetual poverty even more.

MomentJS is great and offers pretty much everything you need time manipulation wise. That being said, I've spent many hours debugging problems with moment because many operations mutate the 'moment' instance that you're working with. If you generate some moments and need to reuse them for multiple calculations, you need to constantly clone them. I wish there was a moment-like library with good performance that's immutable.

JS does not have an Integer type, so (x > 0) does not work. Now if you add all those checks necessary to see whether you're actually dealing with an integer here, you get to a point where you cannot be sure anymore whether there aren't any weird type coercion issues there and need to start writing tests. Suddenly your whole positive integer check took 1h to write and you still cannot be sure whether there's something you didn't think of. I'd rather use an external library for that that's properly unit tested.

Linkedin also wanted to connect me with my dead grandfather a few weeks after he died. I'm pretty sure he never had an account there. Felt a bit weird to have that email pop up suddenly.

Many companies offer relocation packages including travel costs and temporary accommodation.

Because I have no return values to hold on to. Everything in the render function is a side effect. There's no way to collect the intermediate dom representation in data structures and combine it together later. There is no room for asynchronicity from what I have seen. What if I'd like to combine some reactive streams to send me the desired dom structure as state changes over time, piece them together and send them to the renderer?

Virtual DOM approaches never really were about performance. They are about being able to write idempotent render functions in declarative style so that you don't need to deal with massive amounts of DOM state management.

In the end you want to write a function that just expresses what the state of the DOM should be depending on the input parameters and have something deal with applying those changes to a very stateful API. If the application state changes, all you want to do is say 'things have changed somehow, just re-render this component'.

This was possible before with classic templating, but it wasn't very efficient and had problems when dealing with re-rendering interactive elements. You would lose focus on input fields for example, and had to use some post-render hooks to fix the state of the DOM up afterwards.

Using virtual DOM structures fixed this problem in an elegant way and allowed rendering to the DOM to be integrated into more functional programming styles, which made more reactive architectures possible.

It all boils down to humans not being good with reasoning about state changes over time and how to express those imperatively. The only solution to that is not to do it and go more functional.

This is also why I am not a big fan of things like incremental-dom. It ignores the whole idea why we wanted declarative DOM handling in the first place and replaces it with a very imperative and side-effect heavy API. In that case, just use the DOM directly.

I meant something like "cultural fit" screening. If you pay, I don't care if you are a freelance developer, a young couple, whether you are introvert and stay in your room, or tell us your whole life story over dinner.

If you pay for it and want to spend two weeks alone in your room and never talk to us, that's more or less fine. If you live in my apartment for free and you're not getting involved in at least some way, I'll be angry and disappointed.

So that way, screening on CS needs to be much more thorough and the chance that you get disappointed is much higher.

Together with my friends, we are living in a large apartment, so there's often one room empty or extra space for people to sleep. We used to frequently host couch surfers, but in the end we have made the most friends and had the best experience with airbnb priced to just cover the room rent.

We found it to greatly reduce conflicts between guests and hosts, and actually get people more engaged in our small community.

With couch surfing, I often had thoughts like "I pay for your room and you can't even put your dirty dishes away". Since we offered the room for free, we kind of expected some sort of autonomy from their side to help us out in the household or maybe cook some dinner for everyone if they stay longer than one night. They often expected that we would go explore the city with them and give them a lot of attention.

On airbnb that problem somehow mostly vanished. If things with the guest aren't great, at least you get paid. Thus you also don't need such a strict screening process anymore. Due to this, there seems to be much more diversity regarding the types of people we get to meet.

Many of them actually just want a quiet room to sleep in, and it's absolutely fine. Some people however really get involved and become good friends. Especially when they stay longer (which almost never happens on couch surfing), the fact that they pay rent just like everyone else seems to make some of them much more open to suggest improvements and be proactive.

We've met a lot of diverse, interesting people through airbnb, some of which ended up staying for a long time, some coming back regularly. On couch surfing we've mostly met the traveling couple, group of friends coming here to party and young backpacker stereotypes.

What killed couch surfing for me personally though, was that no matter how many people I've hosted, I could never find anyone who would host me when I was traveling somewhere. That really destroyed the magical vision for me.

Reasonable? For the price it costs to get from Berlin's city center to the airport, you could easily drive your own car to Hamburg - and probably back.

I really don't understand why it has to be so expensive. For inner city trips the gas costs are a negligible part of the total price, and most drivers are being paid minimum wage. (I've actually heard quite a few taxi drivers complain about minimum wage being introduced because their employers claim that it's too expensive for them and they need to cut costs.)

Either there are too many taxis out there so they need higher prices to be able to pay for the time where they just stand around waiting for customers, or somebody is getting rich.

I'd be interested in experiences with what IPO means for internal processes, especially in the software engineering parts of the company.

Any more supervision? Did the way development and deployments work change? I can imagine when you're publicly traded the higher ups might suddenly care much more about being on the safe side of things and try to enforce stricter rules.

+1 for the named function expression. I really don't like pure function statements because of hoisting. You often end up seeing functions being used before they're defined which can lead to confusing bugs and hurts readability. I also like that `var Box = function Box (a, b) {}` directly shows people who are new to JS that function declarations are nothing else than just assigning a function to a variable.

I'd recommend adding some more information on the index page. When I arrived I tried to scroll down hoping to find out what this is about, but instead I had to go to the 'about' page myself.

Then I tried to read the 'about' page but the text is very small and the lines very long, so it's hard to scan for relevant information. The bullet points make a couple of claims about what Patoline excels at, but still no code examples can be seen that could give me a feel for how Patoline actually works.

I had to go to 'documentation' and click a small insignificant looking link to actually get to see an explanation of Patoline and some code examples... in a PDF file.

I understand that it's cool to write the tool's manual using the tool itself, but if I come to the website and want to evaluate quickly whether this is interesting and could replace LaTeX for me, I need a quick overview directly on the index page, together with some examples similar to the one on the wikipedia LaTeX page (http://en.wikipedia.org/wiki/LaTeX#Examples).

It also kind of reminded me of Pi calculus (http://en.wikipedia.org/wiki/Pi_calculus). It's pretty fun to play around with and try to understand and replicate those examples on the page.

Isn't that a bit hypocritical? I bought the minecraft alpha from notch at an early stage because of promises of having a modding API added to it soon. Instead, lots of small insignificant features were added that I wanted nothing to do with. I felt they were bad for the game and only focused on short term popularity. Still, it seemed, they were beneficial for the long term growth of mojang, which was the main response to such criticism.

So now notch is offended by a company he backed partly with the money he got from people like me, whose hopes of having a fully moddable open sandbox game made them invest, changing its strategy to allow them to reach a bigger market.

I can directly relate to that, but I cannot say that I sympathize. This is what happens, when you invest in something when it's still in an early stage of finding itself. Bad luck, move on.

I'm already organizing one together with a friend. Stay tuned. We'll post some details later when we figured out a good date.

In the meanwhile, if you'd like to propose an interesting talk, just send us a mail to hackernewsberlin@gmail.com.

We think it would be cool to have a mixture of tech talks and startup stories. I'd love to hear the founding stories of some of the startups around here.

Let's say you want to define a function to be used for a certain operation on two numbers dependent on some boolean.

    if (addition) {
        // operation = add
    }
    else {
        // operation = subtract
    }

If you use function declarations you might run into bugs

    if (addition) {
        function operation (a, b) { return a + b; }
    }
    else {
        function operation (a, b) { return a - b; }
    }
    console.log(operation(1,2));

Here it might happen that you don't get the expected function.

Additionally it's much less clear what's going on. Compare it to this:

    var operation;
    if (addition) {
        operation = function add (a, b) { return a + b; };
    }
    else {
        operation = function subtract (a, b) { return a - b; };
    }
    console.log(operation(1, 2));

Here it's very obvious what's going on and your operation function has a name that reflects what it does.

Personally I prever never to rely on function hoisting and always declare functions using function expressions. It keeps the code style more consistent and it's clearer what is happening in your program.

The variable declaration is hoisted to the top, then is assigned a named function expression `func` so that `func.name === 'func'`. Useful for proper error messages and stack traces.

Something else I'm missing?