Show HN: Super Debugger, a realtime messaging iOS Debugger tool | Hacker News Reader

Show HN: Super Debugger, a realtime messaging iOS Debugger tool

shopify.github.com

75 pointsjbrennan28 comments

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 :)

> if you are using IB

For anything nontrivial, IB is more of a hindrance than an aid. You probably are constructing the view programmatically.

"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!

Definitely. And Super Debugger can be used just as well for IB projects too (some things you can't test out with IB, like a corner radius).

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.

I'm looking forward to giving this a go at work tomorrow!

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.)

You can select a specific view under others with ctrl-shift-click. I don't know anything to help with its over-eagerness to add subviews, though.

Builds on F-Script to give a Smalltalk-like syntax to iOS apps.

You can read a bit more about it here: http://www.shopify.com/technology/7183290-introducing-the-su...

I love when people put a bit of personality into their project pages. Those first 4 frames are delightfully fun. Nice Nintendo throwback.

I was wondering how long it would take someone to recognize that. Glad you like it! I put a lot of work into the project page.

"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.

https://github.com/Shopify/superdb

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.

Well I'm adding this to my current PonyDebugger, Charles Proxy & OHHTTPStubs debugging stack. Great job!

Using the same stack :)

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.

Why would you scrap your work?

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.

Here's a possibly more comprehensive take on the same idea, illustrated by creating a badge:

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.

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.

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.

wow - where are these developers getting the designers to do these landing pages?

I'm the developer and I did the design myself! (I'm not much of a designer, but I try to stick to the essentials. Typography, contrast, and direction)

Reply on news.ycombinator.com