leggetter

Twilio is definitely on the list. The thing I'm thinking about is that, while signature verification is likely the same across products, handling the events is different. For example, SMS and Voice support responses; the webhooks also fetch instructions. So, is that a single skill or multiple skills?

I had access to Verdent during early access over the past few weeks, and I've found it to be better than my previous experience with Roo Code + Gemini/Claude.

A big +1 on the Kafka destination type being a priority. Thanks!

Looking forward to getting your feedback. We feel we've got a good baseline of features with a few key ones planned (Amazon EventBridge, GCP Pub/Sub, and Kafka destinations). But we need the additional feedback to drive the roadmap.

I had the chance to get hands-on with Resend during the private beta and found the Resend dashboard DX features to be really helpful during the development process. HTTP logging, email filtering, and webhooks (also with logging).

Being able to create email templates in React is great, too.

The very best of luck to you Zeno, and the rest of the Resend team.

- TypeScript standalone search docs https://www.tigrisdata.com/docs/sdkstools/typescript/search/

- Tigris Search + Resend demo https://awesome-email-search.vercel.app/

- Source code for demo: https://github.com/tigrisdata-community/awesome-email-search

- Tigris NoSQL DB + Search platform project: https://github.com/tigrisdata/tigris

TL;DR (I work for Tigris, an open source serverless NoSQL DB and Search platform) I was surprised to see that, although MERN isn't as popular as it once was, there's still a lot of people using it and also a lot of new courses being published about building apps with MERN. So, I've created what I'm (admittedly not-too-creatively) calling the TERN stack: Tigris Database (DB), Express.js (web server/API), React (front-end), Node.js server runtime (and dev tooling). The post is what I hope to be an educational resource to help people get started and be productive with these technologies (TERN) as well as migrating from the MERN stack (which is simply swapping MongoDB for Tigris in a one or two step process).

Developer Experience Engineer | Remote UTC±5 | https://tru.id

We believe that telephony SMS and Voice based authentication (2FA/MFA) is broken from both a technology and UX perspective. We are exposing the SIM card authentication mechanism used by mobile network carriers to application developers via our APIs and SDKs.

We're looking for a polyglot developer to initially focus on our web stack (TypeScript/React/Next.js/Vercel), but the role will evolve to include building the tools developers use in both web & mobile (Android/Kotlin, iOS/Swift, React Native) app development.

More info & apply https://tru.id/careers/developer-experience-engineer

It's a good point.

The speedometer is just:

- left: Evangelism - right: Advocacy

The Medium visualisations are nice and would be an interesting/useful way of visualising Back in 2016 I used https://epochjs.github.io/epoch/

You can see the tool used in the context of the related blog post (also linked to from the bottom of the standalone tool) https://www.leggetter.co.uk/2016/02/03/defining-developer-re...

*seems broken - if you mean it doesn't have a responsive layout, you are correct. Best viewed in landscape.

I'm the author. Created this back in 2016.

Works in latest Chrome on Pixel 5.

The pie chart on the right is a representation of whether the activities selected via checkboxes align with Awareness, Acquisition, Activation, Retention, Revenue, Referral or Product (AAARRRP) goals, as outlined in the referenced Defining Developer Relations blog post https://www.leggetter.co.uk/2016/02/03/defining-developer-re... I believe it very much reflects that DevRel is a multi-functional discipline.

Lucky indeed! I've been pushing for us to drop IE7 (and maybe 8) so we can move to more modern tooling and libraries as part of the development process. But customer requirements mean we've got to stick to IE7 for now.

EDIT: But this is an important factor for dev in general http://www.w3.org/TR/html-design-principles/#priority-of-con...

It does seem to be the most commonly used WebSocket polyfill around. We also use web-socket-js [1] for fallback. But Version 3.0 of pusher-js [2] will remove that.

One negative with SockJS has been the complexity of the fallback approach on the client (the browser). Especially when it's only for 8% of connections. A single simple cross-browser HTTP-based transport would remove the code complexity and reduce the file size.

[1] https://github.com/gimite/web-socket-js [2] https://github.com/pusher/pusher-js/tree/r3.0.0

SockJS is definitely a reasonable choice as a base. At Pusher we use a fork of SockJS for HTTP fallback but we actually use em-websocket [1] (ruby) for our WebSocket API. Given the opportunity we'd probably move away from SockJS to something much simpler because we only want the HTTP fallback part and it only handles < 8% of our connections.

If you _only_ want WebSocket connections with no HTTP fallback then Faye WebSocket [2] may be an option. But any production application is going to require fallback for older browsers and pesky proxies/firewalls.

Faye [3] is solid (obviously used Faye WebSocket), has implementations in Node and Ruby, but is a PubSub solution. I'd kinda argue that any real-time app needs at least PubSub functionality anyway.

The ws Node module [4] is apparently "The fastest RFC-6455 WebSocket implementation for Node.js" and receives contributions from 3rd-Eden who is also behind Primus [5]. But it's also WebSocket with no fallback.

I haven't used Primus, but I really like the idea of offering a layer above the underlying connection engine. I've seen contributions to Socket.IO dip in the past (prior to CloudUp being acquired by Automattic), but Socket.IO is used by so many apps that somebody is always likely to maintain it for the foreseeable future. I'm generally in favour of adding abstractions around layers like this (connectivity, DBs, Message Queues, Hosted Services etc.). However, in this case you're then adding a dependency on Primus. Isn't software fun!

[1] https://github.com/igrigorik/em-websocket [2] https://github.com/faye/faye-websocket-node [3] http://faye.jcoglan.com/ [4] https://github.com/websockets/ws [5] https://github.com/primus/primus

This is definitely correct. The article focuses more on data synchronisation where as a lot of services (some of which jkarneges has highlighted) don't offer data storage and focus on letting you define your own feeds/channels/topics/subjects and exposing data updates/changes via messages or events. These services are highly complementary to RethinkDB as it's very easy to see how a channel subscription can map to a changefeeds.

So services Firebase, PubNub Data Sync, Realtime.co cloud storage, the Google Drive Realtime API and Simperium (see: http://www.leggetter.co.uk/real-time-web-technologies-guide/...) are much more in-context to the article.

We started doing this around 3 years ago. It's likely we'll change our default coding style from Node.js style to ES6 and our front-end components to Web Components - browser support pending.

However, Web Components won't remove the need for a service layer which is also provided by the default BRJS runtime or the encapsulation of tests, i18n, config and other resources within a Blade.

Demonstrating how to use BRJS with Web Components (Polymer) is most definitely on our TODO list.

yeah, we have focused on building dashboard like solutions. However, we're undergoing a number of mobile projects right now and we're hoping that part of open sourcing will result in trying to build other types of apps. Hopefully it'll be a learning experience; what works and what doesn't.

I'm hopeful that BRJS will have wider applicability since Blades are conceptually similar to Web Components and I'm sure the hope is that they are widely usable.

We'll see!

It has come out of enterprise focused development - there's no getting away from that. And we have enterprise customers that the toolkit has to support.

However, enterprise is in a state of convergence right now. Those that would not previously work at "Enterprise" orgnisations are providing great value there. Those that have been part of the web development community for some time will hopefully attest to that.

So, what we're trying to do with BRJS is follow that convergence; and be part of it. Some software engineering concepts traditionally associated with enterprise shouldn't be dropped simply because of this association. Similarly techniques and tools that wouldn't have been found in the enterprise shouldn't be dismissed because they don't conform to the expected stereotypes.

For example:

- encapsulation - separation of concerns - interfaces (In JavaScript: arrgghhhh!) - think contracts (function names and signatures). We've had lots of discussions about this but them continue to delivery value when building a maintainable app - services via an IoC/Dynamic Service Locator (see Angular) - PubSub - hopefully Addy Osmani and a number of other solutions have done enough to clarify why this is useful

All these ring of enterprise. But they're actually just good and simple software engineering practices.

When building large JavaScript apps it's about getting the balance right and we're hoping that as part of this open sourcing project we can do that.

One obvious thing that will still stand out as needing improvement are the deep directory structure (from Java). This is high on our list of improvements. We also only export to a WAR right now, but flat file export is also a high priority.

It's mainly a re-write of the older toolkit. Open sourcing has many benefits.

As lead of the open sourcing initiative (not lead-dev) it's been an opportunity to re-evaluate what we're doing and a way to identify things that may change in the future e.g. we used to write JS in along namespaced style. This was - to be honest - nasty. We now use a node.js style, but because we've identified that as something that could change, we have a plugin for that area which means we can move to ES6 or TypeScript if we want to in the future.

It's also been a great way to look at what else is out there, can it address our needs and how can we incorporate it. The obvious thing here is Node.js v Java. We originally chose to write our toolkit in Java as Node.js wasn't around and later on because Node.js wasn't an option for our customers. That's changing so we're looking at Node.js integration. We obviously want our own developers and those of our customers to be able to take advantage of the amazing tools available in Node.js. Java 8 is making things look very good in this respect.

From the point of view of the company there's no doubting that we hope open sourcing will have a positive business impact. The toolkit does enable a very productive workflow when multiple teams are building large JavaScript apps. We built this to solve problems that we were having and that our target customers are likely to have. It's also going to be continually maintained as both our own dev teams and those of our customers will use it.

The UI stuff (Presenter) has been open sourced but we've actually decided to go with KnockoutJS by default as it simplifies the onboarding process. As per this comment (https://news.ycombinator.com/item?id=7429659) BRJS is much more about the toolkit supporting an application structure.

You could look at it that way. But I'd like it to align much more with Web Components and a defined architecture for inter-component (Blade) and service (shared resource e.g. back-end) communication.

I think this comment best describes the focus: https://news.ycombinator.com/item?id=7429659

Right now we use KnockoutJS in the Blade templates. the `data-bind=` syntax is from that. There's not reason you can't use another front-end UI binding library with a syntax that you prefer.

This response provides more about why the front-end library isn't core to what BRJS offers: https://news.ycombinator.com/item?id=7429659

> Why call something a "blade" when you could call it a component or module for instance?it's just confusing and dont help understand what the framework is about. Naming things the right way is important.It means you got your domain logic right.

"component" and "module" are vastly over used in software development so we went with something that was unique and works well with the unique concept we'd developed (~3 years old now). "framework" suffers the same over-use problem so we're probably going to remove that from the intro paragraph.

We specifically went for "Blade" as it works well. Blades represent a vertical _slice_ of application functionality, from UI to interaction with a service layer. Blades contain all the assets (JS, CSS, HTML, config, images) for a single feature grouped together on disk.

BRJS is much more about structuring your application and enabling a workflow that ensures a large and complex JavaScript application is maintainable. It's primarily an extensible toolkit with some core conventions e.g. scaffolding, Blades, Workbenches, Aspects, code dependency analysis for bundling for all asset types etc.

Right now we support writing code in a Node.js-style similar to that which Browserify enables (CommonJS + addition export support) but in the future the toolkit will allow us to move to something like ES6 or maybe TypeScript. We presently have Knockout as default in the Blade templates but we plan to add support for other template types such as Angular, Ember and Web Components (with Polymer). Until we add custom template support it's a small manual step to use these instead of Knockout.

We're only at v0.5 so many things are still evolving, including refining how we describe what it does and the benefits.

This is all useful feedback. So, thanks.

It was initially called "BladeRunner" and one of the main reasons we decided to rename it "BladeRunnerJS" was for Google. As with other JS-based solutions adding "JS" to the end clarifies it's for building JavaScript apps. We've had a lot of positive feedback about the name so all-in-all I think it was a good choice.

Yeah, thanks. Hopefully that's fixed now.

Ah, I understand now. See point 2 here: https://news.ycombinator.com/item?id=7297658

1. I guess I could've removed the "10" bit?

2. I'm running some realtime benchmarks on a number of hosted service providers. If I can get the geolocation it let's me add that to the benchmark results. Granted, a banner that provides info on that would be better than the bog-standard browser prompt.

3. Yeah, sorry about that. I'm interested to see where I'm sending traffic to so am capturing outbound clicks. It seems there's a bug on Chromium on Linux where the `event.metaKey` isn't set to `true` when it should be. See https://code.google.com/p/chromium/issues/detail?id=95874

No. That would be the geolocation API https://developer.mozilla.org/en/docs/WebAPI/Using_geolocati...

You can of course use that in conjunction with realtime web technologies: For example, see: http://leggetter.github.io/100-lines-or-less-js/realtime-col...

Actually, that one doesn't use the geolocation API. It's just a realtime mapping example.

This one uses the geolocation API: https://github.com/leggetter/realtime-visitor-tracker

It's actually a really good use case, but not the only one.

Note: I work on the BladeRunnerJS team - the team behind Topiarist.

I've created visualization tool using Topiarist and a service called yUML that creates a UML diagram showing the relationship between object definitions within a given scope.

http://plnkr.co/edit/WrHHtP?p=preview

The thing that interests me most about this is the potential for changing configuration on-the-fly to deal internal or external network conditions, or simply from additional information extracted from the metrics.

I don't know of any other realtime web service that has this capability.