1
point
colinta
Joined 58 karma
Dev living in Stratford, Ontario. Terminal GUIs (wretched, Ashen), keyboard firmware (Mechy) are my favorite projects, but I'm working on a programming language and runtime to be an alternative to "diff-and-reconcile" style platforms.
meet.hn/city/43.3700899,-80.9818016/Stratford
Socials: - github.com/colinta
---
- 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!
- 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.
- 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. ;-)
- 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.
- 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" ;-)
- 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 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).
- 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!)
- 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.
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.