Atomic Spin

I've had good experiences with Yubikeys thus far. I still have two of the Symantec VIP tokens from years ago that I've never had issues with. I recently bought a Neo to test out NFC (NFC support on the HTC 10 seems deplorable for smart card reading btw). I also purchased a few 4c tokens and so far they've worked great although I haven't been using them for very long.

The gotchas I've encountered while using them on OSX:

- The pins for PIV and OpenPGP are separate as these are separate modules on the card.
- You can't use the PIV or NEO GUI managers and gpg at the same time. You might have to unplug and plug the token
back in when switching back and forth between GUI/cmdline Yubico tools and gpg.
- Forgetting to change my environment to use gpg-agent instead of ssh-agent.
- Typing in my local password instead of the PIV pin when logging into OSX while I have a token with PIV enabled
plugged in.

The "setup" instructions that are referenced in the packaging and on parts of the site are for basic use of OTP. Real documentation is here: https://www.yubico.com/support/knowledge-base/categories/guides/

For people asking about backing up material on OpenPGP modules: these are write only. Generate your material locally with gpg instead of generating them on the smart card itself and use the keytocard command to copy the keys to the card. You can backup your keyring prior to moving keys and restore it before copying keys to each card or ctrl c out of gpg without…

I've recently developed a renewed interest in iOS development particularly because of ReactiveCocoa. The idea of declaratively describing the intent of an action, rather than how it should work, has helped things "click" for me and I'm looking forward to using FRP and ReactiveCocoa in building a few personal iOS projects. I'm continuing to read more about it and this post was very helpful, thanks for sharing. I have a couple additional questions for any seasoned iOS / ReactiveCocoa / FRP devs that would definitely help me along as I progress:

1) Are there any performance gotchas or things to look out for when embracing ReactiveCocoa? One thing thats stuck with me as I read is making sure to understand and keep and eye on memory management, even after embracing ARC. Is debugging ReactiveCocoa code any different than the normal imperative way?

2) What parts of an app shouldn't be handled with FRP? Should everything fit into the framework or is a code smell to handle things both ways?

3) I'm a Ruby Dev and I'm looking hard at RubyMotion as a good toolchain for iOS Dev. It looks like ReactiveCocoa and Rubymotion can play well together[1], but is this a hack? Is there any issue with using Rubymotion and ReactiveCocoa together. Seems like a great fit, but perhaps my inexperience isn't aware of a deeper issue.

[1] http://spin.atomicobject.com/2013/06/18/reactivecocoa-rubymotion/

Often when writing scripts, I'm chaining tools together, e.g. using git to find a thing in a specific commit, using curl to grab something from the web, decoding some json, maybe unzipping a file.

I've never really found any language that feels good for that kind of thing, there's definately a middle ground where it's getting too much for bash, but jumping to a language loses too much at the initial conversion to make it feel worth it until you are well past the point where your future self will think you should have made the switch.

Some languages have things like backticks in php to inter-operate but it's still not great experience to mix between them. For my own little things I'm currently looking at fish, but bash is omnipresent.

This tool seems to delay that point even further, as currently dealing with generating json is definately a pain point (whereas manipulating it in jq is often really good).

But if anyone can point to good examples of this transition in python then I'd be very interested.

edit: jq is more powerful than I thought for creating json, see https://spin.atomicobject.com/2021/06/08/jq-creating-updating-json/

Some alternatives are:

* Just keep your architecture a monolith. You'll do fine the majority of the cases.

* Event-sourcing doesn't require Kafka clusters. Nor do event-driven setups. You don't need complex tooling to pass around strings/json-blurps. An S3 bucket or a Postgresql database storing "Events-as-json" is often fine.

* Postgres can do most of what you need (except for the "webscale" clustering etc)[0] in practice already.

* Redis[1]

My main point is that while Kafka is a fantastic tool, you don't need that tool to achieve what you want in many cases.

> It seems as good a way as any to decouple systems

IMO relying on a tool to achieve a good software design, rather than design-patterns, is a recipe for trouble. If anything, because it locks you in (do you suddenly get a tightly coupled system if you remove Kafka?) or because its details force you into directions that don't naturally fit your domain or problem.

--

[0] https://spin.atomicobject.com/2021/02/04/redis-postgresql/
[1] https://redis.com/redis-best-practices/communication-patterns/event-queue/ etc.

Atomic Object | Developer, Designer | Ann Arbor, MI ; Grand Rapids, MI | ONSITE | Full Time

We are a custom software design and development consultancy. We do a full range of development from high level design prototypes, down to low level firmware on embedded devices and everything in between.

Want an idea of the work we do and the technology we work with? Check out our blog: https://spin.atomicobject.com/

Being an Atom: Atomic doesn't ask that you know a certain language or use a certain process. But we are looking for a certain kind of person—someone who embodies our culture and values.

Atoms give a shit about their work, their teammates, and their clients. We pull together.

Atoms are generalists who enjoy learning and doing new things.

Atoms are great communicators, able to work effectively one-on-one with clients and users.

Atoms are product developers, working on poly-skilled teams to create the most valuable product possible with the client's budget.

Interested in applying? Check out our careers page: https://atomicobject.com/careers

Personally, I think this is very dependent on the culture and work practices of the company in question. I agree that for the average company, training is very expensive. But I don't think it's universal.

If you have a strongly cross-functional, collaborative team, then a new person isn't nearly as much of a problem to bring on. As an example, Atomic Object is a midwestern software development shop that follows practices like pair programming, collective code ownership, short iterations, and a lot more. For them, interships and apprentices aren't a big problem, and have been key to their growth:

https://spin.atomicobject.com/2011/10/04/interns-and-apprentices-at-atomic-object/

I also think it's worth looking at why people change jobs. I agree it's common, but I also believe that sucky jobs are common. If people leaving is such a problem, I'd like to see companies put more effort in to making them happy where they are. Not only would that be the humane thing to do, but it would make the ROI on investing in employees higher.