We are building notification infrastructure for developers at https://www.suprsend.com and looking to hire a senior software engineer with experience in Golang & Python.
I am Gaurav, co-founder of SuprSend. Long time lurker of HN :) I am super excited to bring SuprSend to all of you.
As a developer, then a team lead and later as a CTO, I noticed that every company has a notification module or micro-service which is responsible for sending out communications to end users. SuprSend is a SaaS replacement for such a service.
We built SuprSend to help developers setup a reliable and scalable notification infrastructure within a day. With SuprSend API and dashboard, developers and product owners can ship cross-channel notifications fast, iterate on them quickly and scale easily.
A few features personally I am most excited to talk about are:
* Go Multi-Channel with single API - Your product needs to do a simple event based integration with SuprSend and once that is done, changing vendors, adding channels, modifying content - all can be done without involving developer.
* Smart Delivery - As business we want to reach users for important communication but no channel promises 100% delivery rate hence product ends up bombarding users on all channels leading to poor user experience. On SuprSend, all you have to do it mention TTL of your communication and our model optimizes for your channels without you creating waterfall delivery logic.
* WYSIWYG Template Editors - With SuprSend you can invite your product team to own content and templates without developers being involved. They can modify and test templates right from the platform itself.
* Observability - Logs and Observability is key to understanding what's going on with communications. SuprSend lets you analyse, audit and debug all notifications from a central place, and also alerts you in case something goes wrong and your notifications fail.
If you have built something like this, do tell us about your journey or challenges.
Also check us out at www.suprsend.com, and share feedback.
Seconded! We're implementing it at GitLab and while the documentation could use some work, it's been pretty great. Coupled with some off the shelf modeling packages[0] you can get good analytics pretty quick. We even started on CloudSQL (Postgres flavor) before migrating to Snowflake.
Seconded on snowplow. Piwik/Matomo are showing their age, you don't really control your data with Adobe/GA/MixP/etc, and building from scratch seems easy... til it's not. Either use snowplow as is, or at least learn from it to see how they solved issues so you can avoid some basic mistakes (their data QA on input from the trackers, for example, is very well handled).
From the photos it looks like the display panel is driven by a Raspberry Pi. Adafruit makes it relatively straightforward to build the hardware part [1], now all that's left is the software that processes the audio and displays the visualization.
The panels are from adafruit - there's 4 32x32 panels so you need a beefy PSU to power them.
The visualizations listed there are:
1. an STFT (this is simple to compute - look @ numpy.fft.rfft
2. an energy based vis - light up n pixels where n is proportional to the energy of the frame (this is the integral of the function squared).
3. another energy based vis where if enough energy accumulates particles fall (acceleration proportional to energy).
The code's super kludgy; I'll release it once it is cleaned up.
I seriously don't understand if OP has written this article in satirical sense, because to me there is no logic there.
I am a foreign national, I and my company uses services provided by a US company (email etc.), and this gives right to you guys to collect and ready my emails?
tldr; of your article is this:
"Oh ! he is a foreigner, fuck him. What he can do? ? He can't vote to get us out of power. So, it's ok and about the persons who can vote to get us out, they can't do anything because we know every little dirty secret of them. Oh ! one more thing, we are so good we promise we don't look at these dirty secrets. Although cases where a employee uses this 'secure' system for personal use, ya that do happen. Trust Us."
As a server developer I'm in a good position to implement this, and every so often (a couple of times a year), someone will ask for it.
There are two approaches that could be taken. The first is to attempt to map XML losslessly to JSON. This does not end well. JSON's simplicity as a data structure is lost, because it doesn't support namespacing, on which XMPP relies heavily. For a fun take on this, but grounded in reality, see XEP-0295: http://xmpp.org/extensions/xep-0295.html
The second approach is to drop namespaces, which means dropping the 'extensible' part, and defining some mappings of common stanzas (XMPP 'packets') to and from JSON. This is what xmpp-ftw aims exactly to do (on the client side): https://xmpp-ftw.jit.su/
I personally think the second way is saner, if you accept that you're closing the door on one of the main features of XMPP provides - interoperability between a diverse set of clients.
Now whether the translation ought to happen on the client or the server side is up for debate, and depends on why you feel you want JSON in the first place. If it's simply to ease your life as a developer, the client is better - just use a high-level library like xmpp-ftw and forget about it. If it's because you have some low-end platform where a streaming/SAX XML parser isn't available, you really do want JSON (or more likely, something even lighter) as the wire protocol.
"I personally think the second way is saner, if you accept that you're closing the door on one of the main features of XMPP provides - interoperability between a diverse set of clients."
Might I just add that we are in the context of discussing an article in which that feature was just used. A new namespace was defined by fanout.io and deployed, and it's all perfectly standard and working.
Those who think that XMPP can just drop in JSON don't understand how extensively XMPP uses XML, and probably don't fully understand everything the XML stack adds.
The history of XML in a nutshell is that it was designed for documents, but got used by a lot of people for data. For data, XML was massive overkill. The masses, as usual, overreacted and declared that XML was overcomplicated and bloated and useless. This is not true. It's actually a very nice set of standard functionality to use... when you need it. If you don't need extension namespaces or tag attributes in addition to contents (two dimensions of attributes, basically) or markup in your text, etc etc, don't use XML. On the other hand, if you do need those things, equally strongly, don't use JSON! It turns out XMPP uses all of the above, plus some more. Those who propose switching it to JSON, IMHO, merely demonstrate that they don't understand the tradeoffs in question, and probably have an irrationally-strong aversion to XML.
I, ironically, say this in the context of someone who in my job have almost always called for XML to be replaced by JSON. This is because in those cases, it was the right answer. I suppose, sooner or later, the opposite will happen.
100% agreed, and I'm in a similar position. I often mention to people that XMPP is one of the few places where I think XML is actually the right tool for the job, and is actually being used properly.
This is rather in contrast to those infamous "enterprise" frameworks, APIs and protocols that standards committees shoe-horned XML into as a way to put another tick in another box, that we have all grown to hate. Long may the rebellion continue!
This has been discussed many times, but so far, no clear advantage of changing the wire-protocol, to be based on JSON instead of XML, has been shown. Especially if you want to retain distributed extensibility you will mostly end up with curly brackets instead of angle brackets. Sure, dealing with the DOM in the browser is not awesome, but in general this could be dealt with by having better library APIs instead of changing the wire-protocol.
That said, a minimal protocol addition like this, which just provides an element to wrap serialized JSON for payloads, definitely help with minimizing that DOM pain. I will propose standardizing this as a (very short) XEP (XMPP Extension Protocol) with the XMPP Standards Foundation.
> That said, a minimal protocol addition like this, which just provides an element to wrap serialized JSON for payloads, definitely help with minimizing that DOM pain. I will propose standardizing this as a (very short) XEP (XMPP Extension Protocol) with the XMPP Standards Foundation.
Other than jokes, I think the closest we have to something real is XMPP-FTW, which operates as a gateway and JSON-ifies everything between itself and the XMPP server.
Personally, I'd like to see XMPP go format-agnostic, just like HTTP. What's funny is that there was already a competing protocol that did exactly this called BEEP, created around the same time as XMPP. Developers ultimately preferred XMPP, and I'd attribute this partly to the fact that the payload format (XML) was baked into the protocol. Back then, people loved their XML about the same as people love their JSON today.
Quoting from this article,"Hacking TouchID relies upon a combination of skills, existing academic research and the patience of a Crime Scene Technician.
It is certainly not something your average street thief would be able to do, and even then, they would have to get lucky. Don’t forget you only get five attempts before TouchID rejects all fingerprints requiring a PIN code to unlock it. However, let’s be clear, TouchID is unlikely to withstand a targeted attack. A dedicated attacker with time and resources to observe his victim and collect data, is probably not going to see TouchID as much of a challenge. Luckily this isn’t a threat that many of us face.
TouchID is not a “strong” security control. It is a “convenient” security control. Today just over 50 percent of users have a PIN on their smartphones, and the number one reason people give for not using the PIN is that it’s inconvenient. TouchID is strong enough to protect users from casual or opportunistic attackers (with one concern I will cover later on) and it is substantially better than nothing."
We are building notification infrastructure for developers at https://www.suprsend.com and looking to hire a senior software engineer with experience in Golang & Python.
Contact: superstar at suprsend dot com