cdent

From what I've seen, the people who complain about go's design are people who are more concerned about the ways in which it is not correct (by some definition) and less concerned about just getting stuff done.

I don't "like" go (or any other programming language), but I'm able to get more done in it in a shorter amount of time than any other language, the created thing consumes tiny amounts of resources, and most importantly when I _or anyone else_ goes back to change something weeks, months, years later it's easy to re-establish or gain contextual understanding.

One might argue that if "Spring is such a complex framework" you never should have been using it in the first place?

I'm always confused by these sorts of posts because they happen often so there is clearly a problem but for some reason I've never had much of an issue. I've been using and developing with Python for about 15 years. In that time I've worked on Python projects large (OpenStack) and small (gabbi) and taken over maintenance for some old standbys (wsgi-intercept, paste to name two). Dealt with the 2->3 transition. Released a whole bunch of things to PyPI and relied on far more things that I've pip installed from there. It's been fine.

I don't know what I'm doing differently.

If an entity makes profit off the back of my labour without compensation a reasonable case could be made that harm has been done to me.

Or at least a labourer may legitimately claim they wish to share "freely" only to some. And they can also choose to change their mind on any subsequent work.

This is especially the case when the entities involved are corporate, not individual humans.

Disclaimer: I'm the author of gabbi.

It's great to see more and more API testing tools that use a format intending to be readable.

I personally think YAML is a bit more readable for humans so that's what I used when I created gabbi. Here's a similar test to one of the examples from apitest:

  tests:

  - name: httpbin post
    POST: https://httpbin.org/post
    verbose: true
    request_headers:
      content-type: application/json
    data:
      foo1: bar1
      foo2: Bar2

    response_headers:
      content-type: application/json
    response_json_paths:
      $.json.foo1: bar1
      $.json.foo2: Bar2
      $.headers.Host: httpbin.org

https://github.com/cdent/gabbi

Wow, I completely disagree. What I've read of hers the writing has been great. Tight. No waste. But still very evocative.

Agree. I wasn't at all convinced by the examples showing the Echo was somehow better than using the "built in" signatures, especially since there's quite a bit of handling that Echo (and things like it) makes implicit that you'll probably want to be explicit in some edge case.

Coming from WSGI, I found go's middlwares familiar and positively pleasant.

I too ended up on Chi as the router that worked well without getting in the way.

Consider https://zuul-ci.org/ , perhaps?

Yeah, have to wonder how this wasn't already completely obvious.

I mean, sure, it's great that it's got an official science stamp on it, but really big duh here.

Anybody else get bummed out that many times that we create a lightweight thing to compensate for something overcooked (like XML) the new thing eventually ends up overcooked in much the same way?

Sure, can't dispute what you say. There has to be some amount of "you must be this high to ride this ride" but you don't need to measure 7 times or whatever before thinking the first measure was accurate.

I've been on both sides of the interviewing tables many times and the processes that worked the best were the ones that involved telling stories to another another and seeing how the other reacted. You know, actually interviewing, humans having a conversation.

These sorts of interviews do not find good software developers, they simply remove a certain kind of bad (not really) software developers along with a whole host of very good software developers that don't fit a very specific mold (perhaps people who write cheery blog posts about how fun it was? ...weird). Which is fine if you're the company doing the interviewing, but completely time wasting for the interviewee. In aggregate it sounds like abuse and disrespect. It's dismissive of experience, accomplishment and aptitude in favor of training to the test.

People say that Google has changed their tune somewhat over the years, but their creed has had impact throughout the industry. It's a shame.

Good. I recently told my local honda dealer I wouldn't be buying another of any car because of touchscreens exactly because of the need to look and lack of tactile interaction.

Clearly this change is because of me, specifically, only me. ;)

Yeah, there is a very strong critique of the way in which neighbors on Anarres can effectively be tyrants.

Le Guin is masterful at letting no one and no thing off the hook. No character or society is ever perfect. She clearly has preferences and hopes. Any character or society which intentionally and actively constrains the liberty of another is subject to withering.

I'm currently in the midst of a read through of everything I can find of hers. Started with the Earthsea books (which I hadn't read before) and now in the midst of the Hainish cycle books (on The Telling at the moment). Many of those I had read before, but the differences in me between now and when I read them before are very apparent. I'm responding to the books in a much more emotional way, now.

Left Hand of Darkness and Dispossessed are deservedly the classics. If you've limited time, read those. "Five Ways to Forgiveness" is a very moving collection of five (funny that) novellas in the same story line.

The Telling is proving to be very interesting to me. It is very explicitly about the notions of humans creating culture by learning and telling mentioned in the original post. That is helping to illuminate many of the reasons why I've remained invested in computing and the web, despite many wrong turns.

In my experience, if you find that you're unable to do TDD with a problem you're trying to solve, then you've probably not decomposed the problem enough. In your mind. Step back. Think.

The rush to produce code, now, is making working in this industry suck.

Aligns with my experience.

Which, of course, is only one person's experience amongst many, and different people will have different experiences.

For people like me, however, the problems listed in this article are painfully obvious, especially with regard to false sense of urgency. When everything is urgent, nothing is urgent, except my heart rate.

Slack isn't really the issue here: it's any form of synchronous communication (IRC, someone coming to your desk, getting a phone call). Slack just happens to be the latest flagship for the interruption armada, swooping in with their false urgency and lack of sufficient information.

Huh. I'd say work on "human-computer interfaces" is one of the pinnacles of social activism and always a highly politicised endeavour. The Media Lab has always had (in my fairly long memory) a reputation for empowering individuals in the face of authority. Disobedience is a perfect fit.

If being an "engineer" means not being involved in social activism, why would anyone want to be called or perceived as one?

A thing to keep in mind is that work (at least as it is commonly practised) is not "normal". It's a thing we have accepted as normal, and if you want to be successful (by the common definitions) then, sure, you need to find some strategies achieve some focus and the ability to bring things to completion. There are plenty of good strategies throughout this thread; exercise and meditation are probably the most important.

But you shouldn't feel like a failure or consider yourself aberrant in some way. You're not built for the way we live now. If you're concerned about ADHD, find a doctor. I know plenty of people who have become much more satisfied with their existence after working through that, figuring out ways to adjust their behaviours.

In the end, you need to balance the utility of coping with the expectations of the modern world (and your own requirements for a comfortable life) against an understanding that the way we live now is messed up.

+many to number 4. A super abundance of unit tests (especially if they use mocks) gives a false sense of security at the cost of high barriers to refactoring. Where's the win?

Yeah, same reaction.

There's nothing new in these observations. The ringfencing between OpenReach and the rest of BT has been present for quite a while. It has kept the lawyers and legislators happy and done pretty much nothing for the customer. As far as I can tell this new review from ofcom is essentially a confirmation of the status quo: Yeah, let's leave things as they are but keep our options open.

Even the CEO of BTGroup pretty much said the same: We have most of these guards in place already, we're happy to work with OfCom.

Translation: Thanks bros!

I'll think you'll find that Robert B. Reich's expertise extends a bit further than "reporting".

a) I (the author) am making reference to the impact of bouncers with IRC in OpenStack projects. The error, if there is one, is perhaps that both my posting and the one I reference in the first paragraph are trying to generalize from experience in OpenStack that is not normal. In OpenStack the channels are _not_ 'mostly idling' and that is entirely the problem.

b) It's true that when I started using IRC about 15 years or so ago, I was coming to the game a bit late, at least relative to other internet services I'd used and the age of IRC. I hope since then that I've managed to catch on, but maybe not.

The issue with jargon is only an issue if the the IRC logs are the primary place where information sharing is happening. It goes like this:

If leaders™ are using bouncers and that use is reinforcing the habit of having all info exchange in IRC then, because IRC itself encourages the use of jargon (because it is conversational and personal), the logged information for the project will be very jargony.

Mailing list postings, which are a bit more considered and more broadcast oriented, are less subject to the shortcutting that leads to jargon. Thus a mailing list posting ought to be easier to digest, at any time, by someone who is not as familiar with the jargon.

So the issue here is not that the jargon makes this difficult for those leaders. Certainly they will be able to scan the logs for the hallmarks of the stuff that matters to them. That's exactly why jargon is useful...to them.

It's not, however, useful to other people. This about keeping the open source projects, you know, open.

Hi, original author. Reading the comments thus far (about 30 minutes in) it's like many haven't even read what I wrote.

Sure, the title is cliched, that's on purpose.

Sure, notification can be an issue, but I think I made it clear that that is a secondary issue. The primary issue is that the use of bouncers results in habits which result in the information being inaccessible to other people, other people who may not yet be able to decode the logs.

In other words, to people who are saying "using a bouncer make my life easier": It's not about you. It's about making a conscious effort to make other people lives easier and make projects more accessible.

In what universe is encouraging more babies a good thing. There are plenty of them (and people in general) already.

The concerns in article are intensely nationalistic. Globally we are still a long long long way from the negative population growth that we need as species. That's far more important than what any country needs.