jsnathan

In a similar vein there is docker-mailserver [1].

[1]: https://github.com/tomav/docker-mailserver

If there is shown to be a demand for this kind of terminal UX, someone may well write a native version of it. Possibly it will push some of the existing terminal emulator projects to add new features, or someone will fork one of them.

Either way, it's nice to have options, and it's nice to see innovation, and if Electron makes it easier to innovate we should be glad of that.

Another simple tool of this kind to try out is Marp [1]. It has a live preview, and slides are exported to PDF.

[1]: https://yhatt.github.io/marp/

With this kind of money, she can easily start her own company. Or companies, for that matter.

> I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depending on the problem domain).

> I mean, I get what the article is saying, yeah yeah, avoid the hype, don't drink the 'webscale' cool-aid...

I feel like you're shooting right past the author's point here. What he's saying is that hype, as in the shared excitement, obscures the actual tradeoffs involved in adopting the new technology, and makes it harder to make good engineering decisions.

I'd like to add that it also obscures the available alternatives - simple and straightforward ways to configure / extend existing technologies to have the same behavior / features as that shiny new thing.

And it's not even about what you know ahead of time. I was actually thinking about this earlier today: I often recognize some of the tradeoffs of adopting a new tech early on, but my judgement still often ends up clouded by enthusiasm.

A common pattern of rationalization I often have goes like this:

"Sure this old thing can be used to do the same as this new thing by using functions X,Y,Z, but this new thing lets you do it with just one function. I mean sure, I could write that function myself in about 10 lines, and I only need to do this once for each project, but this is just easier."

I'm not saying that this reasoning is wrong, only that it is biased.

Tradeoffs of a technology, and therefore knowing in which problem domain they are most appropriate, consist of both pros and cons.

The problem with hype isn't that the technology being hyped is not excellent in its own way, the problem is that (psychologically) hype leads us to ignore the cons, to rationalize them away - and this means we're not really fairly considering the tradeoffs.

The author isn't saying that microservices, react, Elixir, NoSQL, etc don't have upsides, but only that (if we are not extra careful) we might not be considering the tradeoffs and alternatives as pragmatically as we think we do.

It's still being debated (for what that's worth) but there are numerous studies that indicate that they do [1].

I don't think we have any workable theory at this point that would explain how exactly (biological) neural networks produce pain, or predict how complex they need to be to do so.

[1]: https://en.wikipedia.org/wiki/Pain_in_crustaceans

I like this, this could be useful. The easier it is to access this kind of information the better.

There are services that have the specific purpose of identifying discussions about brands in real time [1].

Whether that's good or bad depends on how it's used I guess.

[1]: https://mention.com/en/

BEAM wasn't designed for OO languages where all values are mutable objects. It would be highly impractical to try to run Python on top of it.

You'd have to create a Frankenstein interpreter to get anything working.

That's not what he said.

You're probably joking, but if you use a real-time linter, maybe you could run tests whenever the file you're editing has no errors.

You might even try to limit which tests to run based on the test coverage (from previous runs) of the changed functions or statements.

And then there's also ideas like LightTable's inline evaluation [1].

[1]: https://www.youtube.com/watch?v=7YIaHyTdjTY

This looks nice too! Very intuitive interface. Thanks!

Hey! OP here. I submitted this exactly because I kept running into problems with inotify-tools, and other naive inotify wrappers, where tests would execute multiple times in quick succession, or stop executing on file changes, or other odd behavior.

Entr on the other hand works like a charm. You can see on the website that it details a number of edge cases with inotify that it works around. I'm not even sure it's an exhaustive list.

It might be hard to do for an existing site of considerable size, but for new sites it could be done incrementally as features are added.

That's true as long as I'm the only person working on the code. What happens when I need to collaborate with others? Am I gonna be the one to say (the equivalent of), you can't submit this perfectly valid and idiomatic C++ code, you've gotta remove all the templates first?

Choosing Python 2 when I can is like setting in place a simpler coding standard.

I may be in the minority with this here, but I mostly agree with this post. Python 2 is a simpler, and possibly more elegant language than Python 3.

It's true that most of these new features are optional, but that doesn't change that code tends to be written differently in these two languages. I think the relationship between Python 3 and Python 2 is similar to the relationship between C++ and C in that regard.

The goal that all new Python code will eventually be written in Python 3, I don't think will ever be achieved [1]. Personally I'm not using Python much these days, but when I do use it, I still prefer 2.7

[1]: https://semaphoreci.com/blog/2016/11/11/python-versions-used...

As far as the CPU goes, try re-running sysbench with --num-threads=2. Since you get two cores, if your app can take advantage of that, the speed is about the same as the others.

Can't access the article without disabling ad blocker. Here's an alternative source [1].

[1]: https://phys.org/news/2017-02-dinosaur-scientists-collagen-m...

What kind of misconduct? There is a big difference, for example, between plagiarism and fabricating results.

And which percentage of the researchers are involved in this? 1%? 0.1%? 0.01%? Do you have any studies you could link to that in any way quantify this?

China's research spending and number of research articles produced today is second only to the U.S. There are always going to be some bad apples among that many researchers. That should in no way discredit the rest of the profession.

Seems to me that when you intentionally lead people to believe that they can depend on you for something in a way that they wouldn't otherwise have, you create an obligation for yourself to keep that promise.

Should be that way, anyway.

Pretty sure those are all generated. Seems to be a trend of people reposting these throughout the Internet without explanation.

Have a look at the code [1]. There's maybe 20 lines of actual logic in there.

Even taking all of what you mentioned into account, it's still not more than a single afternoon.

I agree with you in general, splintering in open source is a real problem worth tackling, but this is just not a case where it makes any sense to worry about that.

[1]: https://github.com/kennethreitz/maya/blob/master/maya.py

Worrying about split effort makes most sense when the problem is large and the amount of effort dedicated to the problem is limited, or when there are network effects that come from having more people involved in the project. I don't think that applies here.

This library is not going to divert much (any?) effort that could have improved other date-time libraries.

Less likely about Trump, and more likely about the 'freedom of navigation' exercises the U.S. has been conducting in the same general area - something which these sailors would be acutely aware of, and which they may well feel the desire to 'shove-back' on. Not to say it can't be both.

Even in that situation I would think that in the current climate the circumstance of the accident would also be taken into account by the public / the press. I.e. did it occur in a situation where a human driver might also have been unable to avoid it.

It would take a shift in perception, perhaps caused by mass layoffs resulting from the widespread adoption of self-driving trucks, before people would be disposed to hold self-driving cars to a higher standard than human drivers in order to feel safe. But it is not clear if such a shift in perception will occur. People still love Uber, even though the taxi drivers are upset.

I think that as things stand, most people would be OK with self-driving cars if they were convinced that AI drivers are at least as good as human drivers at avoiding accidents (wherever and whenever AI drivers are allowed to drive).

(from the press release)

  > Members of the [President's Strategic and Policy Forum] will be charged with
  > providing their individual views to the President — informed by their unique
  > vantage points in the private sector — on how government policy impacts
  > economic growth, job creation and productivity. The Forum is designed to
  > provide direct input to the President from many of the best and brightest in
  > the business world in a frank, non-bureaucratic and non-partisan manner.

There are an initial 16 members on this council, all current or former business leaders.

I wonder if having both Musk and Kalanick on this council signals anything about Trump's position on driverless car regulation, or will otherwise influence it going forward.

At least one of the major candidates in next years South Korean presidential election (Lee Jae-myung, recently dubbed the "Korean Trump" [1]) is running on a platform of dividing up the chaebol. He is not the frontrunner, but maybe Samsung is partially trying to mitigate their risk with this move.

[1]: http://www.bloomberg.com/news/articles/2016-11-24/harnessing...

Let's do X is not a proposal?

Hey, cool project! Any chance you could give a quick rundown of how this compares to Qubes? Like, the tradeoffs, etc.

That's a very gracious interpretation I think. The snippet illustrates a kind of trivial bug (uninitialized variables) that should really jump out at anyone who is used to writing C code. (And I think it's clearly C code, and not pseudo-C code.)

In fact, it will generate a compiler warning (with -Wall).

The conversation (which OP said was condensed) clearly demonstrates that the interviewee does not understand that the pointer is uninitialized.

To suggest that the interviewee confused it with

  char *p = ...;
  *p = 'c';

makes no sense, because he said the memory was dynamically allocated 'by the compiler'.

Also it would still matter what ... is here.

For example if it was a constant initializer like "string", then the memory would be statically allocated and write-protected.

If on the other hand it was a call like malloc(1), then you would expect some error checking to see if malloc failed.

It's actually a pretty neat little snippet.