colinta

I agree about that specific patterns post being a bad example... but if you google for "react patterns" you won't be starved for examples of more terrible drivel. That's just what's out there, people repeat it ad nauseam. So _good luck_ to anyone who really does want to learn the right thing. From that standpoint, that article is as good or bad as most others out there (old man shakes fist at dev.to).

Even the venerable libraries like useQuery introduce as many surprises as they do benefits. The complexity cost of understanding what is going on under those 20 LOC is quite high – you need to understand "stable values" (which is only relevant to React components), re-renders and how they're triggered, maybe need to understand how graphql fragments are collated into one query document... maybe need to know when useRef is the right way to memoize over useMemo.

I agree with the author, that it feels insane. I would even add to the insanity the lack of quality when searching for help, and the weird rabbit holes that GPT can send you down if you don't already know what "good" looks like.

Yes, it's bad code, and aren't we all having fun laughing at the anonymous dev who wrote it. However, I've seen this kind of code in the wild, and I'd be shocked if you hadn't, too. _Who_ wrote it matters a lot less than the fact that _so many people_ write it. I think that React has optimized for developer velocity, but the primitives make it so easy to shoot yourself in the foot, that in a large codebase with lots of devs, it becomes hard to avoid.

I was one of the Ello devs (mobile, then web, then backend, then all of it).

My guess is that you'll have some diehard fans early on - Ello did, and they stayed to the end (thanks!) and they'll bemoan every single change - just roll with it, trust yourself but also listen to them.

If you get some success you will have a spammer problem (esp porn), but if you limit (better: don't have) public feeds maybe you can avoid the worst of this. Mutual follow makes sense as a way to limit the blast radius of bad actors, but then people will get spammed by friend requests. It SUCKS. Maybe you punish accounts that blast lots of requests but get very few follows back. We did something like this.

Actually one idea that I think would work well: once you have a "this is a spam account" determination, hide those spam accounts from real users, but let them engage with other spam accounts. This will cost you some compute time, but it will give them the feeling that they are being successful without distracting users.

Good luck!

It's built using Hydrogen, our headless CMS and yes it is powered by Remix.

There is a very common thread here- the objc users are happy where they're at, the Swift fans don't understand and want to tell them why their opinion is wrong.

My god, sit down and just nod and say to totals "oh you like ObjC, neat ", or better yet try to understand what they're saying. You do not have to offer your trite condescension.

ObjC is a fantastic language, Swift is fine too but the compiler is slow and breaking changes to the language are painful.

The migration assistant? FFS it only goes so far, and only when it works.

Has anyone mentioned the Book of the Long Sun by Gene Wolfe? If not, I will, and if so, I second it.

Other favorites are Ted Chiang's stories, Children of Time, Dune, and if you want some real escapist but thoroughly fun pulpy hilarity: Dungeon Crawler Carl

Just a fun "experiment in code". Enjoy!

I've been enjoying RubyMotion since its inception, so I'm always surprised by how many people haven't tried it. It's been a huge boon to writing apps.

I cut my teeth on app builder/interface builder about 10 years ago, back in college, and I have never learned to love the GUI approach to building UI (nor do I care for the XML/XAML approach of android/xamarin - just code, thank you).

Since then I learned python, ruby, and don't feel any desire to go back to strongly typed languages. Anyway, I hope more and more people get fed up with Swift and join us in the RubyMotion camp. It's a ton 'o' fun. ;-)

Yes, XML based layouts work just like they do in traditional Android development.

And to chrisdevereux's point, we've already got some Android support in MotionKit.

If you already have a comfortable work flow, I would not encourage you to migrate just for the sake of it, but having the option to write a native app in Ruby is very compelling to a lot of people who might otherwise not be interested in writing a native mobile app.

RubyMotion supports xib files, storyboards, xcdatamodel files, and Android XML files (and localization files, etc), so if you ARE interested in switching, you don't have to stop using those if you're already used to them.

Hi James, it's mostly my fault that your PR hasn't been merged. We tend to focus a lot on the compiler, and less on the Rake commands, but I'll try and get these PRs taken care of soon.

I think the gains are huge, but it depends on your preferred workflow. I know some traditional Xcode developers who kick and scream at the idea of loosing their IDE, whereas I prefer to live in the terminal.

Workflow is one thing, but then writing Ruby code is so fluid. Notice that there's not a lot of preamble (imports and such) that you need to take care of in the Ruby code, I think that's great. But, again, language and workflow are very personal, and I think every tends to "think they're right" ;-)

Yeah I really don't keep up with stack overflow; if I could get emails from SO that I could reply to, I would have a much easier time helping out there. See you in #rubymotion! :-D

And make sure to also check out the physics debug draw video! http://vimeo.com/71388927

This is such a cool project, and Juan has been working is A off on it! Glad to see it released!

I've never seen a better tool for rapid prototyping a working iOS app... and it plays nice with teacup, pixate, all the friends!

Reminds me somehow of Sinatra - e.g. Promotion : Cocoa :: Sinatra : Rails

I doubt this has ever been tried, but I seriously doubt it... the compiler does a lot of work looking at the Cocoa frameworks to build the bridgesupport files. Are GNUStep frameworks built the same way?

The closest thing I know about is Kivy.

I haven't done a larger project, but I did port a small project by starting with just the AppDelegate. It was easier to first turn the xcode project/obj-c code into a library, and compile it as such. The classes "just worked", and with all the nibs in resources/ those loaded, too!

I translated the models into Ruby, and pulled those out of the xcode lib. Eventually the entire codebase was converted (except the nibs).

Yes, and Shizuo Fujita and Laurent are THE top contributors. Both HipByte employees. Matt's last commit was two years ago:

f6908b2 - 2011-04-28 21:50:28 -0700 fixed a stupid bug in the Xcode4 template (Matt Aimonetti)

Disagree. And that's why we have RubyMotion! :-)

If you don't like RubyMotion, then don't buy a license. Plain as that! Thanks Laurent, Shizuo, and the FANTASTIC RubyMotion community!

Aw heck yeah! Xcode never looked so good!

name is resolved, so all the trolls and snipes that are hung up on the NAME instead of the PRODUCT, please continue your trolling and sniping, but on a new topic (like this comment! it's perfect!)

https://github.com/colinta/motion-xray

Thanks! PonyDebugger is solid, though, and much more useful from when you're at a computer. This project is all about getting debugging information from your device.

That's correct - RubyMotion only for now.

do you want me to change the name?

Edit: I'm brainstorming names on the rubymotion google group. F-ing naming, it's so annoying. I'll try and get it renamed soon.

I spent a long time trying to find similar things to what I was building, and of course now I'm finding out about PonyDebugger and this tool.

Different, though, because Kiln is meant to be more generic, and pluggable.

nope, never heard of it.

Who is the "you" you're referring to? Me? I hope not, I'm really enjoying RubyMotion.

Would I recommend it to a company that only does iOS development? heck no. How about a RoR company that wants to do some iOS development? Now we're talking. If nothing else, I think it is a great way to learn the Touch/Cocoa/Foundation frameworks without having Obj-C cruft get in the way of having a good time.