Very interesting! I just started building a CLI for one of my apps to aid in debugging; this means I can scrap that dead-end work. Forked, will check it out.
And feel free to contribute changes back. So far there's the shell, but I think many different tools could be built on this. I'd love to see someone do a column browser for objects.
Fair question. Superdb does what I want: interactive state examination without breakpoints. I hadn't got very far with mine at all, and it was intimately bound up with the design of my app so wouldn't have been reusable even in my own future projects. Then there is the chance that I'll be able to contribute to superdb, something which appeals to my sense of community far more than writing some for-my-eyes-only, debug code for a closed-source app.
Mainly, though, I hate reinventing wheels. I'm not a very good programmer and it would take me far too long. I'll always look for a friendly giant to stand on before I try and build my own ladder.
superdbg is a more fitting name, anyone searching for a super database that's cloud-based, auto-scales, handles web-scale type load for their next generation social network might stumble upon superdb and be utterly disappointed.
This is cool. I have been building an app in RubyMotion and the REPL has been pretty useful.
That said, at least for me, the REPL is a bit overhyped. In most cases the stuff you will tweak with the REPL is UI stuff. But the thing is if you are using IB and designing your screens in Photoshop or Sketch, the UI should be pretty much in place before it hits the code.
As far as other use-cases beyond UI, if you are doing any other type of "testing" in the REPL, you probably should be writing unit tests :)
"Trivial" views are the rule though. And with autolayout, IB is much more important since it's the only way to effectively test the behavior of your constraints interactively. (By setting the screen size to "free form" and dragging the control handle, like a web browser window.)
What are some nontrivial examples? I've only been an iOS developer as my day job for about a year now, and I don't know everything - but rarely do I need to resort to code to do my interfaces.
That said, merging xib's is a pain in the ass. I wish they were more like Android's human readable layouts.
I disagree with the blanket statement that for anything non-trivial, IB is more of a hindrance.
I've worked on a number of large iOS projects over the last four years — I tend to select whether or not to use IB on a per-project basis. About 60% of our projects end up using IB for the majority of their UI layout.
Recently we built a very large educational app for teachers. IB was great — we had a number of key storyboards, most of the design happened very fast. We developed strict standards by which we developed further styling in code (for things that IB couldn't handle like pattern images, and stretchable images).
Merging Storyboards was a bit of a pain — which was exacerbated by the fact that it's much easier for multiple developers to touch a single storyboard than to touch a single xib. But using DiffMerge as our default git mergetool makes things better.
There are definitely times when IB is not suitable — especially if you want to develop reusable dynamic layouts or controls.
But when you have strict specs, designers working on the project in advance, and clients signing off on particular designs, IB is great.
One of the biggest detriments to interface builder is the lack of code review. If you're a solo developer, you can maybe get by without this... but for a team that actively follows a code review process, nib files are black boxes with no searchable history.
Out of curiosity, have you maintained any of your large projects over a long period of time? Did you have any issues with nib files (i.e lots of duplicated bugs? re-introduced bugs? etc?) Personally I've avoided nib files like the plague because of this, but I'm curious as to how others deal with them.
I'm so tired of all the IB hate. IB is a tool, and it should be used when appropriate. Sure you can't do everything in it, but for 80% of even "complex" views, things can be done significantly faster in IB.
Doing all UI creation and layout isn't faster and more "hardcore", it's ignoring a tool that has been around longer than OS X and iOS that was literally made for the job! Have fun maintaining that mess of UI layout code!
Isn't it fair to hate it just due to the clunky interface?
Many times I find it difficult to select a subview under another subview. Or, when adding a subview, it is too eager to be the subview of a subview. Those are the tip of my list of grievances.
I use it! Sometimes it's simpler and faster to go with IB instead of code, and you are definitely right about maintainability. But I sure wish there was something as convenient that wasn't awful to use. That's actually how I feel about all of Xcode. (Yes, I've tried AppCode, I liked it even less.)
"Personality" is one thing, but this is just awful.
I'm a developer, looking at the page to find out about a potentially useful tool. I'm not a graphic design student looking for inspiration; I value succinct, direct information, preferably with short examples that I don't have to go hunting (or scrolling miles) for. (Are there any real developers who seriously prefer a video?)
After the first couple of screens of scrolling with no more than a couple of scattered words, I gave up. The information density is so low that I've forgotten what the last screen says before I've read the next one.
Sooo what you're looking for is the Github readme, available from the button at the top of the wiki page. Wikis are for first looks, readmes are for the skin-and-bones usage guidelines.
I wish the link went straight to this github page. In my experience wikis haven't been worth opening to get an overview of the product. Thanks for the link though.
It demonstrates the creation of a graphical element in a live coding environment. The finished badge is then transferred to an iOS app and tweaked interactively.
One thing that isn't shown is that the code is simultaneously saved to a file within the Xcode project, so live tweaks and XCode project stay in sync.
Although I haven't attempted it, I'm guessing that example would also be possible with Super Debugger. It would require a different interface, but I think it's possible.
>One thing that isn't shown is that the code is simultaneously saved to a file within the Xcode project, so live tweaks and XCode project stay in sync.
That's one thing I've yet to solve for superdb but would really love to get figured out. If you (or anyone) has any suggestions on how to implement it, let me know.
What is the point of linking to that page that doesn't do anything, and making you click AGAIN on the GitHub button? And then you don't go to a description or anything, just the home page of the GitHub project.
30 comments
[ 3.0 ms ] story [ 74.4 ms ] threadYou can read a bit more about it here: http://www.shopify.com/technology/7183290-introducing-the-su...
Mainly, though, I hate reinventing wheels. I'm not a very good programmer and it would take me far too long. I'll always look for a friendly giant to stand on before I try and build my own ladder.
That said, at least for me, the REPL is a bit overhyped. In most cases the stuff you will tweak with the REPL is UI stuff. But the thing is if you are using IB and designing your screens in Photoshop or Sketch, the UI should be pretty much in place before it hits the code.
As far as other use-cases beyond UI, if you are doing any other type of "testing" in the REPL, you probably should be writing unit tests :)
For anything nontrivial, IB is more of a hindrance than an aid. You probably are constructing the view programmatically.
That said, merging xib's is a pain in the ass. I wish they were more like Android's human readable layouts.
I've worked on a number of large iOS projects over the last four years — I tend to select whether or not to use IB on a per-project basis. About 60% of our projects end up using IB for the majority of their UI layout.
Recently we built a very large educational app for teachers. IB was great — we had a number of key storyboards, most of the design happened very fast. We developed strict standards by which we developed further styling in code (for things that IB couldn't handle like pattern images, and stretchable images).
Merging Storyboards was a bit of a pain — which was exacerbated by the fact that it's much easier for multiple developers to touch a single storyboard than to touch a single xib. But using DiffMerge as our default git mergetool makes things better.
There are definitely times when IB is not suitable — especially if you want to develop reusable dynamic layouts or controls.
But when you have strict specs, designers working on the project in advance, and clients signing off on particular designs, IB is great.
Out of curiosity, have you maintained any of your large projects over a long period of time? Did you have any issues with nib files (i.e lots of duplicated bugs? re-introduced bugs? etc?) Personally I've avoided nib files like the plague because of this, but I'm curious as to how others deal with them.
And of course, this tool isn't just for UI tweaking. It's for any kind of messages you might want to send to objects. It's an object spelunker.
Many times I find it difficult to select a subview under another subview. Or, when adding a subview, it is too eager to be the subview of a subview. Those are the tip of my list of grievances.
I use it! Sometimes it's simpler and faster to go with IB instead of code, and you are definitely right about maintainability. But I sure wish there was something as convenient that wasn't awful to use. That's actually how I feel about all of Xcode. (Yes, I've tried AppCode, I liked it even less.)
Typical bullshit, undiscoverable Apple "solution."
I'm a developer, looking at the page to find out about a potentially useful tool. I'm not a graphic design student looking for inspiration; I value succinct, direct information, preferably with short examples that I don't have to go hunting (or scrolling miles) for. (Are there any real developers who seriously prefer a video?)
After the first couple of screens of scrolling with no more than a couple of scattered words, I gave up. The information density is so low that I've forgotten what the last screen says before I've read the next one.
https://github.com/Shopify/superdb
http://www.youtube.com/watch?v=7RkvUX_4Ros
It demonstrates the creation of a graphical element in a live coding environment. The finished badge is then transferred to an iOS app and tweaked interactively.
One thing that isn't shown is that the code is simultaneously saved to a file within the Xcode project, so live tweaks and XCode project stay in sync.
>One thing that isn't shown is that the code is simultaneously saved to a file within the Xcode project, so live tweaks and XCode project stay in sync.
That's one thing I've yet to solve for superdb but would really love to get figured out. If you (or anyone) has any suggestions on how to implement it, let me know.