TomFrost

I love the Remote SSH extension for VSCode (save for the frustrating workarounds necessary for ssh-agent forwarding -- an absolutely necessary feature) and expected VSO to be much more streamlined. But I find myself hitting early walls:

- No documentation on how to clone a private github repo, gitlab repo, etc.

- Cloning a private repo on the command line eschews the ability to bootstrap your VSO instance using the in-repo config, which kills a huge benefit of this product

- No documentation on forwarding ssh-agent or injecting RSA keys of any kind

There are some other needs addressed in other comment threads (particularly registering a remote headless box as a VSO machine) but the above are instant showstoppers. Perhaps this works with private Azure DevOps repos because of the login integration? I'd be willing to wager that the majority of folks interested in this are on other repo hosts, though.

Semantic recently adopted my team's React adaptation as their official React port. It's lighter weight, eliminates jQuery, and all components are standard React components that can be extended or dropped in as-is.

https://react.semantic-ui.com/

ECS is free in that you pay only for the EC2 nodes running your containers -- there's no need to host ECS or do scheduling on your own hardware to use it. It's also Availability Zone-aware right out of the box, making sure the distribution of container instances is optimized for durability. Finally, it's fully managed. No one needs to maintain or upgrade your ECS implementation.

Granted, there's a lot of advantage to building on top of an infrastructure that can be installed on any hardware from any provider. However, we're not talking about rewriting your applications if you need to move away from ECS; it's all still the same containers. Going from ECS to Mesos or Kubernetes when needed is a matter of writing new config files.

It's a very attractive proposition for small teams on AWS who are trying to spend minimal time on ops.

For one, hitting the Github API to put failed build markers against commits and PRs. CodeBuild doesn't appear to have the same Github integration that most other CIs do out of the box.

The problem I've always had with audio interfaces is that input is not private. Requests on public transportation are heard by many. Requests at home turn into a conversation with the roommate, spouse, or children. Requests walking down the street make others question the mental wellbeing of the person talking to him/herself.

I'm reminded of the Ender's Game sequels in which the protagonist wears a small earpiece with an AI named Jane. He communicates with Jane by "subvocalizing" -- mentally saying the words, physically barely uttering a sound. The AI understands.

A few years ago there was a TED talk (forgive me; unable to find the link) on which a technology was demoed to do something similar. Sensors placed around the throat, combined with EEG sensors around the temple, allowed a man to transmit text to a computer by following all the mental and muscle processes of speaking, stopping short of moving his lips in an obvious fashion or making sounds. The sensors allowed the computer to translate their input to actual words.

Perfecting and miniaturizing that technology, then combining it with an in-ear AI, would be a game changer.

If the goal is solely Docker images with a standard size in the 20-40MB range, this can be achieved without additional tooling. After switching our development and deployment flow to docker, my team quickly tired of the 200-400MB images that seemed to be accepted as commonplace. We started basing our containers on alpine (essentially, busybox with a package manager) or alpine derivatives, and dropped into that target size immediately. Spinning up 8-10 microservices locally for a full frontend development stack is a shockingly better experience when that involves a 200MB download rather than a 2GB one.

This is in no way a negative commentary on Nix; it looks like an interesting solution to a well-known problem.

We have an open source solution called Cryptex[0] to handle this. It's better explained by this blog post[1] that gives the thinking and configuration necessary for most scenarios.

[0] https://github.com/TechnologyAdvice/Cryptex [1]: http://technologyadvice.github.io/lock-up-your-customer-acco...

Depending on the data you're storing, you may be responsible for HIPAA compliance. Such a thing is possible on AWS[0], but is not provided out-of-the-box.

[0] https://aws.amazon.com/compliance/hipaa-compliance/

Is there a basis for such an assumption?

For an organization requiring the highest available security, the ideal solution would be a privately operated hardware security module kept off the DMZ. However, that, as well as the idea of self hosting (and maintaining) the entire dev, test, deploy, and prod stack suggested by another commenter, isn't always within reach of a small, agile team looking to focus on their core competencies.

One could argue that it's possible for Amazon to have falsified the description of KMS as an HSM, or the certifications[0] they were granted for it, but I'd retort that an organization in a position to seriously question those claims shouldn't be using a remote solution anyway.

So, making the more rational assumption that such claims by Amazon can be trusted, their offering is quite secure: the HSM does not allow the export of any key, and exposes only the ability to load encrypted data into the device and have it produce the decrypted result over a secure channel, and vice versa.

[0] https://aws.amazon.com/kms/details/#compliance

This is certainly the case, however for an organization implementing best practices for code deployment, such a change would have to be peer-reviewed in the best case, or pushed directly to master with an obvious paper trail in the worst. It wasn't my intention to imply that employing well-designed envelope encryption would shut the door on any possibility of an engineer gaining access to secrets; clearly there's a lot more involved in making that happen. However, this goes a long way to allowing the source of any leaks to be traced should they occur.

KMS is not a centralized secret database -- it's a hosted Hardware Security Module. There is no way to store your service's secrets in it for later retrieval, unlike the solutions listed in the article. I suppose an argument could be made that it still provides a single point of failure, however the risk level of KMS and the SLA it provides is far lower than what one might encounter by maintaining their own server cluster.

TechnolgyAdvice | Nashville, TN | Full time | REMOTE / ONSITE

About Us: We have a full JavaScript stack. React / Flux on the front-end, NodeJS-centric SOA on the back. We're independently profitable, solving awesome problems, and open-sourcing as many of those solutions as we can. Check those out on our Github (https://github.com/TechnologyAdvice) -- DevLab just hit the HN front page yesterday. We're growing by leaps and bounds and are passionate about cutting hours of research out of our friends' business technology decisions. We have a mature and productive dev culture, and get to spend most of our time working on entirely new, modern codebases, with super smart people on a team that's 50% coast-to-coast remote.

Senior Software Enginer (Front-end):

We're looking for engineers who are experienced with React and have a deep understanding of JavaScript. Perhaps you're doing React in your off hours, or are building React on top of an existing tech stack. At TA, you'll be able to work in React / Flux / Webpack full time. Our code base is only a few months old, so there's no need to worry about drowning in "mission-critical" legacy projects.

Apply Online: https://technologyadvice.applytojob.com/apply/DAZ3IB/Senior-...

Mid-to-Senior Software Engineers (Back-end):

We love passionate engineers. Applicants here should have a firm grasp of Node and Javascript in general, but we write microservices and use the best tool for the job, so knowing more outside of that ecosystem is heavily valued. We develop, test, and deploy in Docker, utilizing AWS for everything from hosting to message queues to our data warehouse. Our new microservices-based platform is still in its infancy, so we'd love to hear from architecturally-minded folks who love fresh design challenges.

Apply Online: https://technologyadvice.applytojob.com/apply/kPsEfJ/Senior-...

Product Owner/Project Manager:

We're growing like crazy and have hit the point where we need someone to help us manage a sane agile workflow. At the same time, we're launching a whole new industry-first project, and we're looking for a project manager who also has experience receiving feedback from customers and users both internal and external, and creating/prioritizing user stories for the team. Technical experience is appreciated -- we'd love a PM who understands microservices, messaging queues, and enough technobabble to glean statuses from engineer chatter without a lot of pausing for explanation.

Apply Online: https://technologyadvice.applytojob.com/apply/QEmxsl/Product...

Fair point; I was speaking more toward the case of needing a rebuild any time your container gets changed, due to the change-on-run ethos of DevLab versus the change-on-build ethos of Compose.

But where cleanup really comes into play is when you have multiple tasks. You can specify multiple command paths in Compose, but each one will be a newly built image. With DevLab, you could `lab install` a node project, followed by a `lab lint`, or a `lab test`. You could `lab build` to compile your app at any time. And when you do this, whether it's the first time or the twenty-first time, overhead versus what you'd experience locally is just a second -- and the only image you have is your environment container. No build process, ever.

Member of the DevLab team here :)

Compose is actually part of the reason we wrote this tool. We tried so hard to make it make sense for a TDD workflow, but it was always cumbersome.

Compose wants you to build your application into a container, and build and run that container every time you have a task to run. This takes time and a fair amount of cleanup, especially when you want a clean environment to run your tests that doesn't persist to the next run. DevLab just wants you to specify the environment to plug your application into, and doesn't build a container at all.

The result is:

- No manual cleanup

- No pile of images or processes that stack up

- Your project doesn't have to be a Docker project. It doesn't need a Dockerfile. You can use this for something you plan to clone on an EC2 node and run from an upstart script.

- No Vagrant/Ansible/Chef/Puppet, server config, anything. You pick out an image that matches your environment's needs (node:4.2, wordpress, go, etc., hub.docker.com is a great place to start) and DevLab plugs your app into it.

- More development-oriented features outside of the pure Docker ecosystem that Compose stays confined to. For example, soon, Mac users running docker-machine will get to enjoy ports bound to localhost much like Linux docker users do [1].

To get this functionality outside of Compose, we had a monolithic makefile to maintain all of this for us. It wasn't DRY and it wasn't smooth. I hope you enjoy DevLab!

[1] https://github.com/TechnologyAdvice/DevLab/pull/10

Just today I made a suggestion in a Github issue[0] to use sed for a similar use case. There, it was to generate an Amazon ECS task definition file from a CI tool's environment variables. Using this, populating the list of environment variables by looping through the output of env and including anything that matches a given prefix would be a breeze.

Thanks for the excellent tool!

[0] https://github.com/1science/wercker-aws-ecs/issues/4#issueco...

I'd love to hear back if you find something like this. Up until Vers was released, I lazily boilerplated it into whichever of my services needed the functionality. Even so, the pattern has been such a boon to our development cycles that it seems strange others haven't independently come to the same approach.

You answered that one yourself :) Deprecation means to publicly notify that some API endpoint has hit end-of-life, and that a better alternative is available. If you completely rewrite a service, it's your responsibility to implement the same interface that you had before on top of it. Then you deprecate it and also publish your new api or data schema. Once you get around to migrating the rest of your application's services away from the deprecated endpoints, the next version of the microservice in question can remove that old code entirely.

Imagine Twitter or AWS completely rewriting their backend -- if they were to announce to the public that at a specific time, their old API URLs would 404 and the new ones would go live, it would be a wreck. They'd support the old API through deprecated methods and tell users they have X months to migrate away, if they remove that layer at all. Stress-free SOA must employ that same level of discipline in order to stay stress-free.

--And, functionally, the much easier alternative here isn't to re-implement your old API on top of your ground-up rewritten shiny new service, it would be to reduce your old service to an API shell and proxy any requests to the new service in the new format. Far less work that way. Use more traditional API versioning for the much more common updates. Unless you're rewriting your services every other week, in which case you have an entirely different problem ;-)

You're 100% correct -- interoperability is the key, but you ensure that by making sure everything at the interface layer (whether that's a REST API, a polled queue, a notification stream, etc) is versioned, and the other microservices using that interface include the version they're targeting.

If you include the version at the data level, any time it gets passed into a queue or message bus or REST endpoint, your microservice can seamlessly upgrade it to the latest version, which all of its own code has already been updated to use. If a response is required back to the service that originated the request, use your same versioning package (Vers if you go with that) to downgrade it back down to the version the external service is expecting.

If your interface layer is more complex, having responses independent from the data that change, that calls for a versioned API. Either throwing /v1/* or /v2/* into your URLs, or accepting some header that declares the version. But even in this case, you can drastically simplify changes to the model itself by implementing model versioning behind the scenes.

From your description, it sounds like your pain points don't come from versioning your microservice code; they come from versioning the data models that those microservices either 'own' or pass around to each other. While your approach of collecting your microservices as a collection of submodules is novel, that also defeats the purpose of microservices -- you should be able to maintain and deploy them independently without having to be concerned with interoperability.

While it's possible to alleviate some of your pains with versioned APIs to track changes to your data models, you also conflict with data you already have stored in schemaless DBs when those models update.

In a Node or frontend JS stack, I solve that problem with Vers [1]. In any other stack, the idea is fairly simple to replicate: Version your models _inside_ of your code by writing a short diff between it and the previous version every time it changes. Any time you pull data from a DB or accept it via an API, just slip in a call to update it to the latest version. Now your microservice only has to be concerned with the most up-to-date version of this data, and your API endpoints can use the same methods to downgrade any results back to what version that endpoint is using. And frankly that makes versioning your APIs far simpler, as now you move the versioning to the model layer (where all data manipulation really should be) and only need to version the actual API when you change how external services need to interact with it.

And now your other microservices can update to the new schema at their leisure. No more dependency chain driven by your models.

[1] https://github.com/TechnologyAdvice/Vers

ScummVM has been maintained on GitHub for a few years now: https://github.com/scummvm/scummvm

The downloads are still on SF, though. That's unfortunate.

This article digs on the flattened dependency model like it's a huge weakness of Bower, but this is the _entire point_ of Bower.

You include two models that both depend on two different versions of jQuery. NPM wouldn't complain at all, Browserify would happily package both dependencies up, and now your users are downloading jQuery twice to view your page.

Bower, conversely, raises a red flag right away, and lets you determine what should be done here in the event that the package definition doesn't contain enough info to sort this out automatically. Its goal is to make your client code as minimal as possible.

Feature, not bug.

1. Node.js is (for the most part) single-threaded; that's its draw. It's not trying to be a swiss army knife, and if your use case requires a threaded language then Node.js certainly isn't the tool for that job. But it might find a useful place in your toolbox for other tasks.

2. require() is part of the CommonJS spec, and how it physically works is dependent on the implementation. You point out that Node's implementation doesn't work well in the browser, but Node itself does not work in the browser so that point is moot. I agree that it might be interesting to load remote modules in Node, but keeping that operation synchronous does simplify the language quite a bit.

3. You can also map modules to public or private git repositories in the package.json, as long as the private key used during npm install has access. If the git repo has tags, a tag can be specified in the git uri as well. Private npm repos are the superior way to distribute private modules with wider access, but I think this is handled fairly cleanly already.

Similar library for (Node|io).js, with exponential backoff and randomness: https://github.com/TomFrost/node-attempt

Coincidentally, I had a demo call with Sumo today. I was very impressed, except for one point that makes Splunk the clear winner at the moment: I can send structured logs to Splunk and it automatically finds the keys and allows me to query on them immediately.

Meaning, I can send: 2015-02-02 01:00:00 event="Product sold" price=5

And with zero configuration in Splunk, I can now query: event="Product *" price>2 | stats sum(price)

And in the next iteration of my app, I could add 30 more key/value pairs to that message and could query on the rest of them just the same, no configuration. It makes development incredibly rapid to be able to instantly report on any metric anyone on my team logs out, debug-related or otherwise, without having to maintain some master list of every key in every log message in every service we write.

I was floored in my Sumo call today when I was told that wasn't the case in that product yet. It seems like such a basic feature-- and is why many products have switched entirely to JSON-based logs. Have you discovered a workaround, or find that to be as cumbersome as I'm anticipating?

I'm sorry to say I was once heavily involved in this. I am Kyek, or "Kytek" as the article misspelled. Among other things, I wrote and maintained Appulo.us, and the quote at the end of the article is mine.

While many called BS on the whole "we do it for trials" aspect -- and who can blame them? -- that is, in fact, how this all started. A small group of people on IRC and a forum, who figured out how astonishingly easy it was to dump the entire unencrypted executable from RAM, who shared apps among each other because those little $1-5 purchases added up to a lot when the apps proved misrepresented and worthless. Back then, it was far more common that reviews were gamed and descriptions were blatantly false, and 'lite' versions were quite rare.

I eventually left when that dynamic became an obvious foregone conclusion, and only a very small handful of us continued to purchase the apps that we intended to keep. Frustratingly enough, those who remained and admitted behind closed doors that they were in it for the free apps kept up that mantra, so it became far more of a joke than a meaningful message. I'd have loved to see Apple innovate and find a way to offer developers an easy method of providing time or usage-limited trials, but their response was to dump money into legal rather than R&D.

This article is really nothing new; nothing has changed much from a standpoint of the piracy or Apple's reaction to it since Appulous launched, except Apple's methods are more streamlined and so are the pirates'. However, this article makes the same misleading assumption that all the articles of the past made: They assume that every pirated app is a missed sale.

When you report that 92% of your application's installs are pirated copies, the implication is strong that you've missed out on 92% of sales. That's simply not the case. Many people -- and let's be realistic with the demographic, many young teens who may not even have access to purchase apps on their own -- install these apps just because they're free. If piracy weren't as easily available, I have no doubt that the 92% figure would shrink in direct proportion to the number of installs. Reporting otherwise is wholly inaccurate, and exaggerates the impact that this community has had. And I say that as someone who hasn't supported the community and in fact has spoken out against it for years.

Appulous was an education for me. It taught me about running seriously high-traffic sites, and query optimization and caching algorithms unlike anything I thought I'd ever dig into. Over the past five years that's transported me professionally into a great position where I get to coach dev teams through that kind of work daily, and continue innovating and learning about scalable design. As a vehicle for rapid improvement in my trade, it was a fantastic opportunity. But as for the the lasting impact my contributions have had on the topic and on indie developers, I'm deeply regretful, and disappointed. Apptrackr's proved that if it weren't me, it would have been someone else; it's just a shame that the agenda has switched so obviously from pushing for a better app store to enabling single-tap piracy -- regardless of the _actual_ impact that might have on sales.

Clearly, the next logical step is to make a love song for developers.

This is worth a little more elaboration, I think. If you compile the iTerm2 version of tmux provided on the iTerm2 website (a merge of the fork into tmux proper is pending), then you can link iTerm2 natively to a tmux session.

This means that the iTerm2 window size is the tmux window size; tabs in iTerm2 are tabs in tmux. Horizontal and vertical window splits in iTerm2 are the same in tmux too. And all of this is bound to the GUI, so resizing/reordering panes with your mouse makes the proper modifications in tmux. And because this is a 1:1 mapping of functionality, others using the same native integration will see tabs and split panes get added and removed in real time, as someone on another machine does it.

It's still in early stages and definitely not bug-free, but this is absolutely the best multiplexing experience I've found. Unfortunately, because this is specifically for iTerm2 right now, it's not cross-platform.

We've seen floods of these "What you should have done if your application was interrupted Friday night" articles, but a common theme is to leave out the fact that many of these sites require synchronized data storage, which Amazon doesn't support between regions. If your organization is shelling out the money for something like Riak, Oracle, or the mess necessary to support such an architecture though the likes of MySQL or Postgres, this is all well and good (save for the data transfer overhead costs).

If your application is architected to use SimpleDB, DynamoDB, SQS, or even RDS, these simple "You should have been using Route 53 and multiple regions" articles get increasingly frustrating. Most applications simply aren't elementary enough to fit into that boilerplate structure, and getting around that fact either requires switching away from Amazon's managed database services (lots of money) or writing synchronizing scripts that play nicely with your stack and launching them on additional servers (lots of money and lots of resources).

While ideally I'd like to see Amazon release some sort of feature for multi-region sync, it would be interesting to see how the tried-and-true multi-region businesses have approached this problem.

I can't agree -- among a younger demographic in coastal regions (speaking in terms of the US here), sure, maybe. You need to know what a QR code is, you need to know what app can read them, you have to download that app, and if you're not the type of person that these things come naturally too, you have to learn how to use that app.

That process just isn't biddable for wider demographics. Outside of my tech-savvy group of friends and co-workers, I'm not sure I know anyone with either the understanding or the patience to use them. Until it's far more common for this to be a built-in and automatic feature in mobile devices, I'd be blown away if it ever caught on.

http://picturesofpeoplescanningqrcodes.tumblr.com/

> * Word-addressed memory will make string processing interesting to implement. Maybe in space, everyone uses UTF-16.

Everyone in Minecraft, too -- almost. The string encoding in Minecraft's protocol spec is UCS-2, just a sneeze away from UTF-16. It seems Notch has a soft-spot for large encodings. It makes sense from a calculation and lookup perspective, but I wonder if the increased bandwidth and storage of 16-bit blocks has a measurable impact.