Speaking of auditing checkins. Here's the regex for our code commits, which is enforced at the server:

Fun part is if you screw it up - you have to edit your commit message after committing locally - which is a freaking pain.

(I know everyone here is a git wizard who edits commit messages with one finger 20 times before breakfast.)

I have. I built basically a toy app to round robin code review assignments and handle GitHub webhooks to ping a person on slack when they've been tagged to review a PR.

It's a pretty impressive language and framework.

Coming from Ruby/Rails, I really dig the pattern matching and the multiple function definitions where the correct one is matched by arity.

Phoenix felt really nice to use. Basically it felt like a less bloated Rails. Pretty easy to pick up and run with. The speed was impressive coming from rails. Response times in microseconds rather than milliseconds locally at least.

The biggest challenge that I came across was authentication. Unless you wanted oauth specifically the ecosystem was lacking. I was able to glue some pieces together and get the job done though.

For your use case Phoenix could be a good solution. Concurrency is where it and the language really shine. Though there are a number of questions for you regarding the implementation.

How will your elixir app get the data it needs? My understanding is that it's not recommended to have multiple applications connected to the same database. You'll need to sync code changes on both platforms to make sure any schema or serialization changes get handled properly in both places. I'm not sure if there are any other issues that could crop up.

How are you going to leverage the sockets? Most traditionally you'd push changes from the server when they occur. But all your events will be happening in a different application. You could poll from the client over the socket or have a periodic job push over the socket, but I think all these really save you is the overhead of negotiating a new connection for each poll request. Not sure that really justifies the build.

Correct me/discuss where I'm wrong please!

Super dumb question about Cassandra and NoSQL. I was just told by our resident hazelcast people that they can only do key/value retrieval, no queries. Fine that's how they set it up - as a session cache.

However, when we said we would just use our own cassandra instance. He said you can't do queries with cassandra and still have it be distributable.

So basically we're saving these rules objects one at a time through one part of the node app. The objects themselves have a primary key. Then periodically I want another part of the app to say "give me all the rules" - which node will store in resident memory. So select * from the rules table basically. I find it hard to believe this is something cassandra can't handle and still be distributable.

Cassandra automatically distributes data by default. This has nothing to do with your queries. They probably messed up the table design.

This gives a decent illustration of what Cassandra does:

http://docs.datastax.com/en/cassandr...ndraIntro.html

Cassandra is highly optimized to fast reads, taking a little hit on writes. This is done, in part, because everything is basically select * from tbl.

I think this stuff is more what they're kvetching about: https://www.datastax.com/dev/blog/ba...-data-modeling

Hi. I have what I think is an incredibly simple question that I'm hoping someone might be willing to help with. I'm building a website on squarespace and want to embed an interactive map. I built the map in qgis and exported it using leaflet, but when I go to embed it on squarespace, I get an error message saying the url is not embeddable. I also tried copying the code into a code block, but that didn't work either. In case its not clear, the extent of my programming skill is 'google the problem I want to solve and blindly apply solutions until I get one that fits.'

Thanks for your help.

You mean around example 2 on that page?

To work around this, you would actually have multiple tables that do the same general thing. You insert into each and select from each one, reflecting the queries you need. It's a denormalization-first approach where duplication of data is encouraged.

Here's a general idea: http://docs.datastax.com/en/dse/5.1/...gApproach.html

So if I know my query is going to always want all members of a table. And those members are small objects, which may end up being a few hundred total in the table - how do I proceed?

The only other query is to add or update one member at a time.

Talk about an area where NoSQL falls down compared to SQL. Select * from a small table is never a problem with a traditional SQL db.

Cassandra allows you to select and aggregate individual columns from a table. A few hundred values shouldn't be a problem for selecting 2 columns from a 3 column table, for example. There is no logical reason to partition a table of that size or create clusters.

Cassandra's basic approach to working with big data is removing joins, which is why denormalization and data duplication is it's chosen approach.

Yeah this makes the most sense. Our operations teams just don't understand anything but max partitions and clustering.

Hmmm - https://news.developer.nvidia.com/ai...gns-into-code/

Well, so long front end developers I guess

I think it could possibly make their jobs easier - by making boilerplate. But how can it handle interactions, animations, responsiveness to many devices and screens? There's a lot of art in that - at least to making maintainable code.

ffs react is finally free from the patents bull****.

Flash, Dreamweaver, and Visual Studio did an awesome job of removing the need for front-end programmers.

But guys, this time it's backed by deep learning

It's obvious this will be great, just consider how easy it is for a FE developer to make a website just by looking at screen grabs of the design.

Heh

Question for you web dev guys. So I'm working on this new personal project where I track my Roomba around the apartment. It's a pretty fun engineering task given the semi-arbitrary constraints I have, but that's not exactly what I want to discuss here. Let's assume I have a perfectly working algorithm that outputs positions in near-real-time.

Now what I want to do is build a web page to display the results as they're updating (as well as the ability to scroll through previous results, but this I think is more straightforward). I don't really know much about the web technologies, but I have enough coding experience to learn what I need to for a small-scale task like this.

So I'm imagining a server process listening for messages. Probably only need 2: "start new track @ date/time" and "add position @ (x, y)" (HTTP messages or something???). Files/logs/whatever can then be updated easily. What I don't really get is the client-side updating. I want to be able to have the web page loaded and have the track be updating without the page reloading every time. Given this does that = JavaScript? And given new server-side information, does that = AJAX?

Got a simple python Flask web page working on Heroku, because I sort of picked that before thinking about the dynamic requirements (and partially because I know python well). Is that going to be completely unnecessary and I should be coding an HTML/JavaScript page given the previous paragraph? Or is it still going to be useful?

To recap my biggest unknowns:

• How should the "messages" be passed? HTTP?
• Am I supposed to be using AJAX?
• Does the python/Flask stuff still fit in anywhere? General architecture advice?

Thanks guys.

You will still need a backend component of some kind - python/flask is fine, nodejs would also be fine if you wanted a 100% javascript stack etc. The backend can collect data however you want - the roomba-monitor can send data to it by http or whatever you choose, not super important.

The front end should probably be a persistent javascript app. That is, once you load the page, the javascript runs continuously and fetches data from the backend.

You can do it discretely, like, every X seconds ask the backend "what's new since last time". AJAX requests are fine for this, sure. There are also "websockets" which are basically more or less like tcp sockets that follow a specific protocol. It's somewhat remniscent of IRC if you remember that. Anyway, it's a connection that you keep open over time so you can stream data back and forth instead of HTTP requests, which are discrete.

I think either way would be fine. With websockets you could prodouce something that draws updates in real time, without it would be in discrete chunks. How much that matters depends on how much changes per unit of time.

P.S. are you using these new broadband tiny antennae that can provide indoor positioning down to about a centimeter? They look totally sweet.

Thanks for the response!

Let me see if I understand correctly... with AJAX, I'd essentially be pinging something server-side every X seconds (or maybe in a continuous loop?), so my visual updates would then be tied to that sampling rate. With websockets - is there some kind of callback/event-driven method so that code can get called automatically when the server sends something over?

Just technical curiosity I guess, because I think even a very slow sampling rate (0.5 or 1 seconds) would be totally fine. My algorithm may not even end up being real-time. So do you think one is easier to learn or should I just pick whatever?

Oooh I am not; never heard of these, but I am very curious to learn more. Got a link?

I'm very very interested in new techniques, since I don't have something in mind that I really like. Right now, I have a RPi+camera+IMU system that's packaged up and will be mounted on the Roomba. I've got a rough track right now with pure IMU odometry, and am thinking I can augment with some computer vision/object recognition. A visual SLAM thing would probably be the holy grail but I just haven't gotten around to trying to find some code. Oh, and plus, the camera kinda sucks and blurs super easily, which is why I'm currently ignoring the visual odometry algorithm I wrote.

The obvious solution that would make this trivially easy would be to have stationary cameras that just recognize/track the Roomba from afar. But there's no 1 spot that can see enough of the area, and I just really don't want to be mounting multiple cameras in the corners of the ceiling. Minimal environment modification is for sure a self-imposed constraint, but if those antenna things you're talking about are small and don't need LOS, and I can stick them in the corner of the room or something that could work. Oh and this is supposed to be a super low budget project too

Ajax is request response so would need to be fired on intervals. Websockets are literally just pub sub and almost certainly what you want here. Look at socketio.

websockets are bidirectional. So, you can send info to the server, you can ask the server for info, or the server can stream info to you as it gets it. It's much more efficient to do this if you want very up-to-date information.

This is sort of a press release for a cm-resolution one
http://www.embedded-computing.com/ne...or-positioning

And I think this guy is using something similar, in the previous generation:
https://hackaday.io/project/18296-lo...ization-system

I've done a fair bit of different kinds of image processing stuff. By far the biggest problems I've had are that cameras suck (good ones exist but are expensive) and that conditions change a lot (like say lighting).

I've read some really good books on robotic navigation, that might interest you. I really liked "Probabilistic Robotics" although admittedly I have not implemented anything based on the techniques in it
https://www.amazon.com/gp/product/02...?ie=UTF8&psc=1
although I have n

There are probably some interesting low-tech low-cost methods. I honestly don't know how much these positioning antennae cost, I have no use for them.

Here's something I might try: Put a really bright LED on the roomba. Use 2 cameras to capture room views. Filter channels to pass through LED color and block most everything else. When you have direct LOS it should be easy to locate the roomba, when you don't, I bet that you could infer it from the general pattern of light on the walls, by using known positions and matching outputs from the cameras, and a machine learning algorithm.

(I kind of feel like it would work in theory, but, well, you know)

That 2nd link is using stuff from these guys (or maybe they ARE those guys)
http://www.localino.net/shop/localino-hardware/

Cool, sounds like I'll go with WebSockets. Seems like there's python implementations too. I'd really like to not have to learn all this node js server crap just for this little mini project that I spend 1-2 hours/week on.

Ugh yea I'm not really willing on spending more than another $50 on this. I either want to learn something/implement a really cool algorithm or have it be really cheap. I don't REALLY care enough about where my Roomba is cleaning to pay hundreds for the solution.

Hmmm this is actually a very interesting way to get around the LOS problem - especially since most of the blind spots are in a narrow behind-the-couch corridor. Might just try taking an old backup phone and turn its flashlight on, then just mount my Rpi system where I can see most of the room. I may try this...