zinkem

> Putting on a 'stateless' boxing glove won't mean there's no difference between punching a guy once or twice

There are still side effects in the system, of course.

But what your database looks like afterwards is the important part.

Can you recover lost data, replay transactions, undo, etc etc?

Whether or not your service does something useful is up to you.

A database on it's own is enough for most business applications.

If you haven't seen this yet, you're just rent seeking.

Idempotency is easy if you don't use mutable state in your middleware.

Auth, logging, and atomicity are all isolated concerns that should not affect the domain specific user contract with your API.

How you handle unique keys is going to vary by domain and tolerance-- and its probably not going to be the same in every table.

It's important to design a database schema that can work independently of your middleware layer.

I believe this research is totally true-- I had a lot of memories come back after

1. I stopped drinking heavily and using other drugs, i.e. marijuana

2. managed my diet to avoid heartburn without medication

3. schedule my meals so it was easier to sleep at night (always eat something for breakfast when I wake up)

I did not need any "poo infusion" or anything.

I had a gal bladder removal that didn't fix the problems the doctors thought it would and got a lot smarter about the kinds and variety of food I eat.

I believe alcohol in particular was really screwing up my gut biome and entire digestive system.

> Strange game, the only winning move is not to play.

What a tired aphorism. Just like PG's 50 year old insights.

I most commonly use random() for generating names (e.g. docker's container names) and generating test inputs. I don't care about cryptographic safety in either case.

> Microsoft teams is an extremely high quality product already.

This has not been my experience with MS Teams. If I respond to a message on my phone, and then return to my laptop, Teams has disconnected and I have to restart the app on my laptop in order to get updated messages. Scrolling back even 5 minutes in Teams' message history incurs multi-second latency sometimes, so reviewing the context of a conversation you're in is very painful. Threading is handled very poorly in teams and makes teams feel much more like a decades old forum than a chat application.

I do agree this is a good move for Slack, but only because organizations are adopting teams due to its bundling with Office 365, something most companies are already using. Slack has no other way to survive because the people in the org making these decisions aren't concerned with the quality of the tools they are choosing, just the idea they are getting something for free.

I've been using the Markdown Reader Chrome extension and using the browser print function to do this kind of conversion.

What would be really useful (to me personally) is a tool that renders plantUML/mermaid embedded into markdown to a PDF. I haven't been able to find a simple solution that doesn't require writing code to integrate the libraries together, or rendering the images separately and bringing them into the markdown document (which is tedious).

> any stage of the request or the response L4-L7 at FPGA speeds

I also work at F5, and used to work on the FPGA. This is unfortunately not true for TCL iRules. The FPGA basically only operates on L2-4, L7 is all software.

There was some talk about doing L7/iRules in an FPGA but prototypes never produced compelling enough performance gains to make it worth it.

Not mentioned in the article, but bit packed data structures are easier to interpret in hardware and offer more guarantees. If I'm designing an FPGA/ASIC I can predict how many clock cycles a statically sized data structure will need to move through my system, and how much RAM I need while it's being processed.

I have spent a lot of time working with FPGAs that process network packets and many of the performance guarantees relied on the rigid structure of L2-4 protocol headers.

I agree with others here that learning a language has a lot to do with learning an ecosystem, libraries, and culture. To contribute to an existing project, it's not necessary to really know the language that intimately. I "know" a handful of languages, but I have contributed in environments that I don't "know."

To learn languages quickly, I think the best way is by learning the 'building blocks' languages are composed from. How are function arguments passed (value vs reference), how is memory management handled (garbage collected, reference counted, manual?). Learning these lower level language concepts then allows a person to approach a new language by saying "How does this new language X handle concept Y?"

I'm not sure where you're getting your pricing, but the Monologue is $299 [1] and a new MicroKorg is $399 [2].

The MicroKorg is a great piece of equipment, but it's also prone to aliasing problems at the upper end, which shouldn't be present in the Monologue since it's all analog.

The MicroKorg also offers different features: FM Synthesis and a Vocoder. The Monologue has a full 16 step sequencer, wheras the MicroKorg has only an arpeggiator.

For this price point I think a lot of mucisians are going to find the Monologue is a good value. It isn't far off the MiniBrute which came out at $400 and has less features.

[1] http://www.sweetwater.com/store/detail/MonologueBK

[2] http://www.sweetwater.com/store/detail/microKorg

For those who are curious like I was, the flagged words/phrases are:

just

actually

sorry

apologize

I think

I'm no expert

does that make sense

reasons are in the source here: https://github.com/cyrusinnovation/just-not-sorry/blob/maste...

so post some cat pics then

In all honesty, I think it'd be more interesting to see analysis of turing complete OISCs than repeatedly seeing these minified homework solutions posted to HN

I hope there's a laugh out there for some of you ... =|

I have the same feeling... I've been to places with the expressed goal of understanding and integrating into the culture, only to find out after I've left that there were actually 2 groups within the company: those that wanted change and those that wanted things to stay the same.

> Yet, here we are, over 30 years after the original IBM PC was released, and there's still a corner-office audience for "what is a computer?"

As someone who got their start on DOS and BASIC back in the 80s, I say you raise a pretty good point. There are so few languages depicted in this web brochure that it does not illuminate anything.

So many people stopped learning in the 80s that the 50s are starting to catch up with them again.

This is the stuff that cardboard box forts are made of.

This should be a yawn for those with web and mobile dev experience, people I'd expect to already understand virtual machines and fractured encodings.

This is probably the most relevant post in this thread.

I recently left the working world after realizing I really don't need that much money to be happy. In the turmoil, I realized some things I had read or thought that were a little misguided and almost burned all my industry bridges completely, thinking "f--- that place anyway."

But this comment really hits on something I've felt throughout the whole thing... eventually you just get tired of the games. And maybe one day I'll get back into the working world, but for now I have what I need.

I'd actually love to see this done on a Genesis. The Genesis had an FM Synthesizer in it's sound chip, made by Yamaha.

The Super Nintendo has a distinctive and pleasant sound that I like, but only outputs a 32khz signal.

I really like projects like these using old sound chips as instruments.

Terrence McKenna explores this hypothesis in his book 'Food of the Gods.' Part speculation, part historical account of the role of chemicals in human culture. Great read if you're interested in this kind of thing.

390 of which were only released in Japan.

The xbox actually had ~900 games and the GameCube had ~700.

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

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

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

I don't think it quite works this way... if you deposit $1000, the bank isn't required to keep $1000 on hand, so with your 1/30 ratio, it means they would hold onto about $34 and loan out the rest with interest.

I am definitely not an expert on banking.

This comparison to steam is a bit of a false equivocation. I can run Steam on a variety of hardware configurations, which I can buy from a variety of vendors. Steam is better not because the DRM system is different, but because it's hardware agnostic.

Once the XB1 lifecycle is over, I have no guarantee I will be able to play the games I bought. As far as I'm aware XB1 is not backwards compatible at all. Once my 360 dies, if I can't find another one in working condition, or XBL stops offering services for the 360, my 360 XBLA games are gone forever.

I think that claim could also support that they "mustn't" be brought down.

I think it's really cool to see this practical use of genetic algorithms.

I've written a few toy systems in the past, and have been told by (at least a few of) my mentors that GAs are a waste of time and can't solve any real problems.

I often come across these types of comments about the IRC protocol being 'crufty,' 'old,' etc. I recently (a year ago) implemented a subset of the IRC protocol for a project and I thought it was fairly modern, and not difficult to work with.

Yes, IRC has some problems, it wasn't built with security in mind. I think dsl below offers a solution to some of these concerns.

But this still leads me to ask the question, what does a modern distributed chat protocol look like?

I'm not sure I see the distinction you're identifying. If you're ever written code on the iPhone, everything is done via events. All the code you write is responding to an event fired in the runtime. Any synchronous network calls you make will block the UI thread, so asynchronous calls are the right way to access network resources. This same reasoning is why Node.js libraries are primarily async. It's the right thing to do.

edit: To expand, the alternative is to fire off threads for each connection so you can write 'synchronous' code... the whole point of nginx and node is so that you don't need the overhead of creating a separate thread for each connection, asynchronous code is the natural result of this decision.

It actually isn't completely alone in using an asynchronous paradigm, as you suggest. Delegates in iOS/Cocoa and events in Java work in a similar fashion. Function-queue architectures are not unique to Javascript.