Same. Immediately I thought why not have clawdbot ask you for the 2FA? That way you at least kind of know what security-protected action it's trying to take and can approve it
The problem is baked in - he gives it access to iMessage, which is where all the sms-based 2fac codes end up. There is no way to prevent it reading 2 fac codes if you want to give it full text message access
Just to be upfront, i've gone from one of the naysayers to a modest fan after spending some time using Claude Code on nights/weekends with tasks that I know I can do and how long it would take me in order to get an idea of productivity gains possible with the tool. So far, the money i've spent was worth the results i got.
However, it's shocking to me the blinders people have with these things. Security is supposed to be front and center in our industry with everything we build and do. I thought that lesson had been learned and learned well over the past 30 or so years of life on the web. People are going to get seriously burned and the only answer to them is going to be "well you should have known better". For a fishing analogy, Barracuda are circling just out of visual range biding their time but the strike is inevitable.
If you're using these agents, spend some time attacking them and see what you can get them to do that you thought would be impossible by default. If you find something say something, we're basically having to re-teach the whole Internet basic information security again.
Foreign keys have a different set of tradeoffs. We'd have to either look enum values up before making the query, or use a join that might affect query plan.
I grumpily ignored the comments about mobx for a while, then finally broke and used it on a small side project. The results were...
...disheartening. Because (at least for my team and the specific projects we do), mobx was much much better.
(Disclaimer: We use React to incrementally replace/upgrade pages and panels in a very large admin console. So we have a ton of very small apps that share a lot of concepts, but are still distinct apps. Obviously this multiplies the amount of boilerplate we have to deal with compared to if we were using a single "monolithic" SPA.)
Key advantages:
1) Way, way, way less boilerplate. With redux you soon grow used to the dance of adding a new sub-reducer, a new batch of constants, a new batch of action creators, then wiring up the new action creators to your container, wiring up the new state sub-trees to your container, and boom, now you've got some props that represent your data, and some functions you can call to change that date.
With mobx, you add some new observers and (optionally) some actions to change those observers and...you're done. It feels odd at first; when you're used to redux you're used to setting up a new app (or coming to grips with an old one you haven't touched in a while) as a very elaborate process. With mobx the "skeleton" is done before you even really start. It's almost worrying.
2) Redux has some very specific ways it wants you to structure your project, and some of them are quite good. A junior dev might struggle to grasp what's required to set it up from scratch, but I think for an intermediate dev it can be quite helpful. It strongly forces you to make some good choices about data flow, seperation of concerns, logging, etc. But for a senior dev it can be a little...limiting. I actually know what I'm doing, and sometimes the right answer doesn't 100% fit into the Redux way of doing things, even if the "redux way" is great 95% of the time.
Mobx allows a lot more flexibility. I suspect that could be a drawback in some cases too, but for this particular case, it's quite nice. You can actually implement a number of different patterns on top of mobx, including a redux style state tree, or (as we've done) some Backbone/ActiveRecord style models. Which obviously have a lot of limitations and are great for everything, but are really great for our specific use case.
3) On a related note, redux really needs data to be normalized; you end up devoting a remarkable amount of time to normalizing data (using normalizr or whatever) and then de-normalizing it in your components to handel relations properly, and then figuring out how to modify your normalized state tree in your reducers based on actions triggered in your denormalized component tree. Totally doable, but a pain.
Mobx makes it easy to use references, avoiding the entire issue.
4) Closely related to the last two points, components written with redux in mind often end up with very extensive lists of props, because they end up needing a little bit of data from six different reducers, plus a dozen action creators. It works. It's fine! But...
...with mobx, at least the way I'm using it, you can generally get away with just passing in the relevant model, You keep ending up with situations where you pass your ProductList model into your ProductList component, which maps over the Product models it contains and passes them into a component called Product. Your actions are just methods on the model class. Components with 1-2 props are easier to reason about and (in my experience) easier to test.
All of which is basically just 4 different ways of saying that for me, it lets me type a lot less (which is good), but most of all it lets me think more about the problem I'm trying to solve, and less about the libraries I'm using (which is key).
Thanks for the taking the time to write this up. I'm using redux for the first time and I really hate it. It may be the least DRY state management approach I've ever seen. This will be helpful in convincing my colleagues to give mobx a try on our next project.
What do you hate about Redux? I went from Flux to Reflux to Redux and it really makes state management easy from my experience. You should give the idiomatic redux videos at egghead.io a try: https://egghead.io/courses/building-react-applications-with-...
Is it possible to have the same thing but over websockets?
As Lambda can also listen to DynamoDB, it would be quite interestig to have an ability to forward this kind of events to browser clients.
This is exactly how browsers render SVG filters currently, and it looks the same edgy on my non-retina Mac too...
And that's why I've included a separate script (make-screenshot) which uses PhantomJS and ImageMagic to render high-quality hi-res version of your wireframe. I used that to produce screenshots for github readme.
Another option is to try zooming-in a bit in browser, like to 125%, this way it looks a little bit better imho.
You actually create wireframes in (angular- and bootstrap-enhanced) HTML with Shireframe. And yes, you can reuse some of the code when creating actual product.
I'm not really into graphics editors and enjoy writing code much more.
The goal for me was to simplify creating wireframes with code by having a set of predefined "sketchy" styles and several ready-to-use UI widgets and shortcuts for common layout patterns/classes so I don't have to create and type them in from scratch for every new wireframe.
This already saved me a number of hours as I'm creating some wireframes on how a future product at my company will look like.
