thenrich99's comments

ASET Partners | Senior Fullstack Developer, Senior Software Engineer | Full-time | REMOTE | US Only | Go + Python + React + Kubernetes + Terraform + AWS + Postgres + GIS

ASET Partners is developing a geospatial intelligence platform and we're looking for talented individuals who enjoy working on a small team that moves fast and makes significant impact. Applicants must be able to acquire a Public Trust, be US citizens residing in the US, and submit to a technical pre-screening.

Reach out to tim [dot] henrich [at] asetpartners [dot] com for more information.

ASET Partners | Senior Fullstack Developer, Senior Software Engineer | Full-time | REMOTE | US Only | Go + Python + React + Kubernetes + Terraform + AWS + Postgres + GIS | ASET Partners is developing a geospatial intelligence platform and we're looking for talented individuals who enjoy working on a small team that moves fast and makes significant impact.

Applicants must be able to acquire a Public Trust, be US citizens residing in the US, and submit to a technical pre-screening.

Reach out to tim [dot] henrich [at] asetpartners [dot] com for more information.

ASET Partners | Full-stack Software Engineer | REMOTE (US) | Full-time

ASET Partners is building a geospatial analytics platform used by analysts across the US. We're looking for individuals to join the small but talented team to help us continue to build out the platform and develop new products and capabilities.

Tech stack includes: AWS, Terraform, Kubernetes, Go, Python, Django, Postgres, React, etc.

Requirements: must be able to obtain a Public Trust

To apply, send your CV to tim [dot] henrich [@] asetpartners [dot] com

I'd hardly call Kubernetes, Docker daemon and tooling, etcd, CockroachDB, geth, and nsq tiny CLI projects.

If anyone has any reservations about learning Go, don't judge the language based on a list of flaws written by some programmers who used it for a few months, became frustrated, and wrote a blog post.

Go has tradeoffs just like any other language and plenty of programmers leverage it for its positives: https://github.com/avelino/awesome-go

What does it mean to have a "language that can scale"?

Go is a language that's easy to use, but a challenge for beginners to use well, especially if you try to force [insert another language] constructs into it.

I see programmers that are new to Go often struggle with trying to apply their object-oriented mindset into a language that's not object-oriented and run into trouble, complain about the language, and call it rubbish. Or, focus on the lack of generics and other part of the language they don't like (e.g. slice manipulation).

Go is certainly far from perfect but after spending the better part of 7 years with it, it's usually the first tool I reach for.

Nice work! I built https://cronally.com a few years ago for a similar use-case.

Keep it up!

Also check out https://cronally.com -- you can schedule HTTP requests or hook directly into SNS.

(Creator here)

Yes, this is plain telephone conferencing and the landing page could definitely do a better job explaining that.

API Gateway + Lambda might still be an upcoming deployment option for this. App Engine was chosen as the initial deployment target because some of the additional features that will be added are cheaper / free for low volume usage when compared to AWS. This already requires Twilio, so releasing this initially for App Engine seems to resonate better.

Elastic Beanstalk's Multi-container environment can be a nice way to ease a project into containerization, but it seems like it doesn't get much love from AWS these days. You're still forced to set hard memory limits on containers even though ECS support soft limits.

Shameless plug: I was also tired of the absurdity around configuring various CI environments along with my local development environment, dev, staging, etc. Every new configuration variable required a change in 6 different platforms, so I created Environr (https://environr.com) to centrally manage configs in a way that works well across all platforms.

> On the other hand, if you work on medium-sized systems (and those are much more common than large ones), immutability is too expensive to work with.

Care to elaborate on your experiences here? Mine have been the opposite for smaller systems.

> Only if you're stupid enough not to package your dependencies, if you use distribution not suited for servers (like Fedora or Ubuntu non-LTS), or if you use external repositories you don't control that don't have stable retention policy for packages. And mind you, these three were always a bad idea. Appearance of Kubernetes and other magic faerie dust of Docker haven't changed it.

Valid point -- though I would still argue that packaging and distributing dependencies at the container level is easier to get right than at the system level. I might be in the minority, but having managed custom RPM repositories for projects and leveraged tools like FPM, (Effing Package Manager), the move to containers was a huge win in terms of flexibility (each container having its own dependencies) and organization.

Thanks for the feedback!

We support JSON in the CLI so users can access the response data with tools like jq (http://stedolan.github.io/jq/), but leaving off the json parameter will respond with human readable output.

The pricing is regrettably not up yet, but we'll definitely work on some other examples.

Cheers! Tim

Amazon Data Pipeline and Cronally solve different problems.

ADP is a complex service designed to transport and process data between AWS products in a time-sensitive manner. Minimum intervals of 15 minutes and the inability to run jobs on a set of existing machines (i.e. running a shell command pipeline requires a separate instance launched for each execution) doesn't support a number of use-cases.

Cronally is a simple platform that augments an existing AWS cluster by allowing those same machines (or others) to perform work, while handling locks transparently and supporting resolution down to the minute.

In this scenario a replay attack is limited to a 30s window during which the timestamp is valid. Depending on the implementation, this may or may not suffice, in which case an nonce would definitely be an improvement albeit with the added complexity.

Original author here -- thanks to everyone for the feedback. Some time has passed since this was originally written and the remaining languages were never updated to improve the safety of the signature verifications.

The original reasoning behind this post was to provide a single reference for signature generation and verification in some common languages -- something I struggled to locate myself. Admittedly, I should've provided warnings about using simple and hardcoded keys in the examples, which were done that way for readability.

While there is still a lot of debate about the ability to perform true constant-time comparisons in many of these languages (https://bugs.python.org/issue15061, https://github.com/joyent/node/issues/8560) I agree that for those who would be otherwise using the unsafe string comparisons, the benefits certainly outweigh the slightly added complexity.

The updated gists are available in the post to anyone with comments or improvements.

Cheers!

I developed Task Science (https://taskscience.com) to manage, categorize, and collaborate on ideas and tasks. The goals were to remain quick and responsive so you can add the idea and get back to work.