baystep

Bit weirded out by the idea that it installs via a batch file that the Readme dedicates a chapter on how Windows will flag it as a Trojan. As well as the fact that it mentions it is a 30 minute demo, but only does so buried in the Readme. Just feels suspicious to me.

I chose to make this as an extension so I could quickly inject data for unit tests and UI previews. I've thought to pulling out the code and making it a library as well, but Faker and chance already exist in the JS ecosystem.

I wonder if something like Nunjucks but with CommonMark could work great for the document web.

As an American living in Turkey to produce software systems for the Education industry. It is in my honest opinion this is mostly all false. Evolution was not removed (if I'm correct it was shifted in which years it was taught, pushing it later in the primary education years). Jihadism is not on the agenda at all. But some south-eastern/eastern provinces do place Islam studies on the bill (in historical manners). It's much like how the US has a "Bible belt" in the south where creationism is taught along evolution. Turkey has a "Quran belt" in it's south-eastern border that also places more emphasis in religious teachings along side it's sciences. In the western portions this is essentially non-existent besides the historical context (Ottoman was Islamic after all)

Reliability of the language and tool sets is a big one. Availability of coders in the language is another, there's an over abundance of C++/Java coders looking for work, but finding a team of Rust developers is a bit trickier.

Also in general, I would start with a list of languages that are built-for, or can easily support, what your product is. For instance, I love Go but wouldn't use it for a GUI application.

And in honesty, managed languages are a bit better in my opinion for projects that will require many devs to work on it. As much as this statement might catch flack, C++ is wonderful and powerful and I trust my ability to use it; but do I trust the workforce to? It's very easy for a dev to write a patch fix that also manages to introduce a memory leak or null pointer and crash the whole thing.

Gorilla Mux isn't bad either and is pretty tried and tested.

Also Go is one of the few (if not only?) languages with HTTP/2 built in to the standard library. Not to mention the gRPC over TLS that comes stock as well.

I don't use an ORM currently, just plain 'ol SQL queries. And in actuality I prefer it SOO much more. Like originally I was using Hibernate with the Java JPA, but I found it just got in the way a lot and the dependencies where finicky. Where as in Go and raw SQL I know EXACTLY what it's asking for and can pre-compose my queries externally. Any changes to the tables I have to make, as in renaming or adding columns, is just a quick change to the SQL query itself. And if needed, 1 line added to the Struct definition.

Also I'm more of a custom approach person which makes me very productive with Go. It's allows me to have laser focus on my needs instead of hooking up and reading docs and every little integration feature the framework has. And in result, I don't have dependency on a monolithic framework which could very well break everything in it's next release.

And finally, Go will build to binary for any-platform. So I can pre-build for the ARM processors, or Linux, or whatever else on Windows and just ship the binaries for server updates instead of managing make scripts and dependency resolution and blah blah blah. And if I wanted to I could sell the API "program" and sleep a little better about the IP contained in it (yes I know de-compilers exist). I could do this with C++ as well, but that's a whole 'nother ball game when it comes to tracking down memory leaks and segfaults.

Backend: Java (phasing out), Go (phasing in), Postgres, Redis, all on Ubuntu EC2's.

Frontend: JS (TypeScript/ES6), React, ReactNative, SASS, all Webpack'ed (except RN).

I think it's a fairly light stack but am happy with it. I would use this as the starting point for pretty much every project.

What about the "I've lost that email account, can I switch it to another to recover my account?" case. Or the "I'm the legal guardian of this person and need the account control switched to my personal email", or in the business world "this employee doesn't work here anymore and as administrator I would like the account transferred to me" cases. Locking customer support systems down tightly has it's own pros/cons.

I was actually making an open source sim city clone in JS myself a while ago. Didn't get this far at all, but I was mostly in it to test if I could get async updating from the simulation portion. Essentially doing threading in JS. Which I was somewhat successful in using Web Workers and shared buffer arrays, would be interested in helping with this project. Unfortunately in my research I didn't find any concrete documentation on how the simulation algorithm actually works, so I doubt this would end up a direct clone on SC2K.

I just upgraded myself to a 4K 28" monitor. Mine has 1ms response time. I noticed a slight loss of productivity in the initial stage, but really just because I was getting used to it. Now I'd say it's increasing productivity since I don't have to Alt+Tab all the time anymore. I can fit 4 source files comfortably now. So, in regards to your drop in productivity, I'd say give it time.

Essentially, I was going down this route if anyone's curious....

http://code.flickr.net/2012/12/12/highly-available-real-time...

This may actually solve an issue I was about to tackle, which is high-speed notification delivery. Currently I was going to do a nasty wrestle of PUB/SUB with Lists and blocking keys to try and get a cluster of message processing servers to digest notifications when they get added to the "queue". My purpose in this is notifications, as in actual push notifications for mobile/web/etc. This seems like it fits perfectly with what I had planned. Especially since this ensures message delivery instead of fire-and-forget as you mentioned. As a question though... is the XACK commands working in your current branch? Since that is key to my usage of ensuring message consumption.

Right, which I figured if there was any viable way to get sender-identification working then that would be solved at the initial point. Like HTTPS requiring a Certificate Authority to vouch for you. With out the certificate, the receiving server could effectively reject it. Should stop all those pesky SMTP senders claiming to be X website as well. You know, since for some brilliant reason the "from" field is just taken from input, you can type anything you want in there.

Email is one actually. Notoriously hard to work with from a systems point of view, and based on a protocol that's been minimally updated since it's conception in the early 90's. It's essentially been 25 years of the same old crappy standards that have been duck-taped to hell to try and fix security vulnerabilities. I always meant to re-write a version of email that works better with servers and API's. Such as JSON message formats, async key handling natively (no need for PGP anymore), sender identification and authoring, etc. But it's a massive undertaking, and I can't do it alone with my work schedule.

Right, but I'm thinking the server still needs to be able to say "This person who ever they are is definitely the number you have". Like, I wouldn't check my password hashes with only the first 10 bytes, I guess that's why I'm still stuck on the truncated idea.

But that sounds like un-necessary round trips. I feel like the point in an API or backend service doing this, is because it knows better and has more computing power. I'd rather have my service take an incoming list and return with whether it's a member or not. In fact returning full hashes seems even worse, since now the server has not only replied with the correct match, but potentially more strangers. You could milk an API of it's users much quicker that way.

If it's only one year I would keep working. But spend much more time on my own projects to start a business with. If it's indefinite, like basic universal income, I would release more open source projects since money would be less of an issue.

Yes, but if (it seems more like when) a collision happens in a situation like this, aren't we essentially saying someone is connected with someone they don't even know? I feel like detecting the collision takes more computation then just sending the whole hash right? I mean in consideration of the scale that Signal/WhatsApp/etc are with millions of phone numbers

As someone who is going to implement "find-my-friends" in this way, and wants to do it conscientiously, may I ask why only the first 10 bytes of the SHA1? Isn't that just an incomplete hash that could collide with other valid numbers?

Could you add/did you add killing the annoying "call to action" pop-up dialog? You know, you visit an article and BAM! A fullscreen modal asking to sign-up for their book newsletter? That would be awesome.

Moving away from Java w/Spring to Golang. Java and especially Spring with it's dependencies just didn't operate fast enough on simple requests as part of a Restful JSON API. Spring was too bloated with dependencies for tech we weren't using and didn't plan on it. As well as setting up VPS servers to run the resulting JAR is kind of a pain as well. So Golang & Rust is going to be the new stack it looks like. Comes with the added benefit of 0 dependency and byte-code compilation so if we decide to sell we aren't packaging _too_ much of the IP with it.

Have you ever tried Gulp? Honestly I had the same feeling with webpack, I like it for my "professional" day job project that's grown to huge size and webpack can chop through it quickly; but for side projects, probably not.

Then I found gulp. Uses a more functional streaming style, but for the end goal of [Turn ES6 into ES5]->[Stick it in this folder] it's dead simple and quick.

"Write this blog or your fired"

I've honestly had a strange experience with Win10. On my home PC I built I installed Win10 from an OEM disk (not the off the shelf edition) and I'm not sure if that made it different, but I loved it then. Worked flawlessly, just deleted the stupid XBox icons and was never bugged again.

Then I got a work issued laptop with Win10, and it's been ATROCIOUS for me. I don't have any ads or whatever (is this gonna be a new feature?) but my permissions model is royally screwed. For instance, I had to activate root administration controls on my user, cause you know, it's my computer. And some how because of this, I can not run the built-in Calculator app. That's right, can't run the calculator because I'm an admin. I had to write my own. So it's been hit and miss. But so is my story with every OS.

Coming from a Java background (as far as back-end API development goes), I've pretty much fallen in love with Go. I will definitely be using it on all future projects of my own. That being said, my pros are numerous and my cons are limited. So far they might be:

- A bit too much boilerplate. The infamous "if err != nil" statements will get a bit tedious. BUT! This keeps you on your toes, not in the same way as Java's "NullPointerException" explosion keeps you on your toes.

- I agree with the 3rd party libraries comment. Any cool library I find spends 2/3rds of the README talking about benchmarks. Like we get it, Go is fast. Good luck finding any actual implementation besides "read the docs". And sure someone could write examples, if the package lived long enough.

- I wish there was a tad bit speedier development. The compiler is QUICK, but for something like server development I find myself having keep the command line going, use the "go install" command, then run the exe (windows) from the bin folder (I put it on the Path just to save my life a bit), then test, then kill the server, and repeat. Not great for quick prototyping. In comparison my other web techs have live-reloads, where saving re-compiles, kills the current process, and starts. I'm sure I could rig one up, so this is probably just a nuance of my own early travels in Go.