toadkicker

PAP is a protocol for zero trust AI agents. It features several examples including e-commerce transactions. Built on existing standards.

> "Have you worked at a FAANG or on FAANG level problems?"

"I have not, do you have those problems with 10k users too?"

Studies show computers running less code perform faster

Ironically Apple is also the ones who kicked off the entire PWA race because of the lack of an SDK when the iPhone launched. The messaging then was "build for the web, that is better than native" and now its "native or gtfo" and web apps are not preferred. The last 5 years that I've built web versions of apps first, the client told me "look the web app is great, hard to tell its a web app honestly. Except when I want to..." and you all know the rest of the conversation from here.

Firefox, I love you, but you're bringing me down. We need a powerful, semi-native, offline capable architecture for the web. I don't care about the PWA spec, it's quite messy handling the implementation of one. But I do think it has always been the vision that the web is accessible regardless of physical connection to it.

As long as I can remember in this industry we've swung back and forth between "thin" and "thick" clients as if one way is the right way. Microservices over monoliths, etc. It's all the same symptom that naturally we don't want to grapple complexity. This announcement is yet another entry in the cannon of thin vs thick. It's a hard problem and any PM who only cares about optimizing time spent will say everything they can once they've zeroed in on the perceived waste.

I can't believe on this page "Users" exists. What happened to Apple's brand language? "Now you can" would make more sense to the reader.

I can't count how many times I've submitted a patch only to hear my supervisors complain that I made a contribution to the thing that makes the business profitable.

We set them up that way and then someone who isn't so strong with networking opens it up to 'fix it'.

One of things I absolutely despise about the JS community is this obsession with build tools. JS is meant to be a runtime language and the amount of transpilers, minifiers, uglifiers, obfusicationifiers, is absolutely endemic to the messy state of change the language is undergoing.

However with this release I'm excited to start deleting a bunch of ridiculous build code to make Webpack work. Really a build tool is a tool, it should never be in the way of developing features. I haven't enjoyed using webpack until now. No sensible defaults, poor documentation, and no standard conventions. This release changes all of those complaints. A boost for productivity is a win in my book.

It is currency and it should be regulated. Algorithmic pumping and dumping is illegal in most countries, so why should cryptocurrencies be exempt?

Their QA department has been in a downward spiral since 2014. I would love to name some people who were doing a fantastic job running the place until then, but I'll spare the embarrassment. This really isn't about some mega company not caring as much as one of their cornerstone departments being unable to function effectively.

Just wait until artificial intelligence does it for us...

No I don't think you need to do that to get interested in it. If you want to see it in action and spin up a playground really quickly, I suggest using Embark (https://github.com/iurimatias/embark-framework). (I contribute to this project)

I use http://mailinabox.email which totally automates running your own mail server. Highly recommend taking a look at it!

"Wordpress is a remote shell with great blogging features"

The client/server model is great for capitalism but no good for liberty.

I just wanted to add some positive comments here complaining the state of the web as we know it today vs. the people who are working on the solutions to the problems. There are well defined paradigms for building distributed systems. While much of the web was built in the belief these distributed systems would take root, lots of engineering went into client-server configurations. There are a ton of psychological reasons why these decisions were made. They don't have to keep being made though. We can all embrace distributed applications (some call them serverless applications) and free the web once again. Here's a lot of great projects that are trying to do just that: http://github.com/toadkicker/awesome-ethereum

In the second article the author explains what a 'JSON pure' api would function. It completely throws out the OSI model and provides no way for the application layer to react to transmission errors, which HTTP codes provide.

It's really silly that is how the culture behaves. The right tool for the job is a common moniker in other industries, yet in ours its the source of heated debate and hipsterdom.

It's better to be part of the solution than to create the problem.

Programming is akin to woodworking. Lots of tools and all of it is for wood. Use the right tools to craft the right solutions.

Yes it comes from statistical mathematics

Give SNS/SQS a look for polling solutions for API Gateway. We got around it by having a health check call in our set up.

This is the way good things get done. New ideas should come from anywhere they can and the best ones bubble up into the product. Always reset expectations if anything that does get said ends up being misread. Let's face it; text is a horrible medium for communicating complex ideas. Open the communication channel accepting things at face value.

"Code as its written" fine for collaborators, bad for over zealous managers.

So what exactly is your point?

> Our designers strive to create layouts that best fit the business and shouldn’t be limited by what framework we choose to use on the front-end.

Name any framework that doesn’t have an opinion about how to do something. A good developer is also one that sees a design and knows what tool fits it best.

>To use Bootstrap efficiently and understand it well you need to dedicate time to reading through the documentation, digging into the source code and figuring out how to customise it for your requirements.

Again, name a framework that requires 0 documentation reading time on the part of the user.

>Bootstrap doesn’t follow best practices or good semantics

This is an opinion best served by backing up what you feel good semantics or best practices are, because often times frameworks define what those best practices are.

This is where I find programmers who are comfortable with static languages struggle with dynamic languages. There is a lack of understanding and this is yet another language trying to fix something that isn't fundamentally broken.

I didn't want my comment to devolve into an argument about the merits of static vs. dynamic. My comment is really to ask why would I use Typescript for web programming? Where does it fit? It doesn't seem to fit in or fill a need that isn't already possible with any combination of static and dynamic languages used separately. In fact I feel it blurs the separation of concerns between static vs. dynamic.

Why do I need statically typed languages to compile to Javascript? Isn't it just better to learn functional programming and dynamically typed languages?

Bravo, thanks for ruining my productivity today.

All the same that Wordpress could easily adopt using environmental variables for configuration values to achieve this and simply use a heroku-ified version of config.php. I've used this approach for scaling wordpress sites and its never failed me.