Disqus - Latest Comments for listrophy

Re: 2014 Rails Rumble

Bradley Grzesiak — Fri, 24 Oct 2014 11:06:28 -0000

Do you mean mobile native? Because if not, it should work out of the box as mobile web. All parts of the site *should* be responsive.

Re: 2014 Rails Rumble

Bradley Grzesiak — Fri, 24 Oct 2014 11:05:32 -0000

Thanks for the feedback! We're aware of a couple issues, one being the problem you described. Once judging is over, we plan to address this.

And yes, events (especially with "I'm bringing" aspects) outside of Facebook is exactly what we're going for. :D

Re: Single Responsibility Principle & iOS | The Bendyworks Blog | Bendyworks | Ruby on Rails, iOS, & Clojure Consultants | Madison, WI

Bradley Grzesiak — Thu, 08 May 2014 06:01:37 -0000

In retrospect, I'm thinking it might be informative to try this again with a single Intention-holder object in the Storyboard. Yes, it's another level of abstraction, but I don't know how that would *feel* until I try it.

The idea, of course, would be to have the UIViewController be the object that modifies the view in reaction to model changes (some might call that a ViewModel), while this Intention-holder object would modify the model in reaction to external forces (view-level actions, network callbacks, etc).

Re: Single Responsibility Principle & iOS | The Bendyworks Blog | Bendyworks | Ruby on Rails, iOS, & Clojure Consultants | Madison, WI

Bradley Grzesiak — Thu, 08 May 2014 05:57:17 -0000

I have not done this, but I suspect the problem is that Storyboard Scenes automatically retain the objects hydrated in it while loading a NIB file from code does not. Assuming you're using `-(NSArray *)loadNibNamed:owner:options:` from `NSBundle(UINibLoadingAdditions)`, the documentation states:

"You should retain either the returned array or the objects it contains manually to prevent the nib file objects from being released prematurely."

I'm not sure what mechanism would be best in this situation, but I would say that adding a line or two in a UIViewController's setup/teardown methods isn't so bad.

Re: Single Responsibility Principle & iOS | The Bendyworks Blog | Bendyworks | Ruby on Rails, iOS, & Clojure Consultants | Madison, WI

Bradley Grzesiak — Fri, 07 Feb 2014 15:46:57 -0000

Thanks for the input. It's actually quite enlightening...

I do think I have some refactoring to do. The first one is that the call to validation ought to be triggered on the text field delegate side. The view controller would then pick up a change to an "isValid" key, probably on the PersonProxy object, since NSManagedObject apparently doesn't provide that. That, I believe, is a better approach.

Second, I took the approach of creating multiple Intention classes per Scene. It was illustrative, but perhaps it went a little too far. I could see merging the different Intention classes into one IntentionHolding class with multiple Intention IBAction methods inside it.

Lastly, rather than responding to the save notification, a BOOL property on PersonProxy could be `isComplete`, which the VC observes and decides to segue based on that changing to YES.

Re: Single Responsibility Principle & iOS | The Bendyworks Blog | Bendyworks | Ruby on Rails, iOS, & Clojure Consultants | Madison, WI

Bradley Grzesiak — Fri, 07 Feb 2014 14:24:10 -0000

Thanks for sharing. To clarify, I said "branching factor in... structure." What I left out was the origin of the term "branching factor," which lies in the tree data structure. A tree with high branching factor has nodes which have many, many children, whereas one with low branching factor might have nodes with 2 children each.

Let's apply this to class architecture. Given the "throw everything into one VC class without categories," we have a high branching factor because we have a VC with (too) many methods inside it. By introducing Categories, we lower the architectural branching factor by adding a layer. That is, we have a VC with many Categories; each Category with many methods. By scoping the work within Categories, we have less cognitive load, because there is less context to be concerned about.

So as I've said, Categories are good! Great, even! Everyone should use them! But this article is not about Categories. A carpenter does not have one hammer, nor do they have one saw. Exploring other tools is a good thing.

And finally, extracting a piece of functionality should not hinge on whether than functionality is reusable or not. In Uncle Bob's Modem example in the SRP chapter, it should be safe to assume that neither the Data Channel nor the Connection interface are reusable, yet they probably should be separated (depending on the context, of course, while taking into account Needless Complexity).

And with that, I think I've found our disagreement. You think this approach is an example of Needless Complexity. I, on the other hand, think this is worth exploring and refining before making such a declaration.

Re: Single Responsibility Principle & iOS | The Bendyworks Blog | Bendyworks | Ruby on Rails, iOS, & Clojure Consultants | Madison, WI

Bradley Grzesiak — Fri, 07 Feb 2014 11:17:48 -0000

Let's constrain the discussion to SRP and VCs, since that's what the article is about. I did not advocate for the other 4 principles in SOLID.

Now, the first thing to ask ourselves is "Is SRP something we value?" This is entirely subjective, and my answer obviously is "yes." I accept that others may feel differently.

For the purposes of my argument, I will take SRP as a desired trait in code. The question then becomes "How do we intelligently and responsibly apply SRP to our code?" A sign (though certainly a heuristic and not a rule) of a class disobeying SRP is a high branching factor in its implementation's structure. A high branching factor increases cognitive load on the programmer which is not desirable. Using Categories, I would agree, is a good solution to solving this problem if used to correctly separate logic; it inserts an extra layer of abstraction between the Class and the methods thus logarithmically reducing the branching factor. The approach I took in this article is different than Categories, since I feel that using Categories is well enough documented and explored. Instead, I'm proposing an alternate mechanism to compartmentalize code which is entirely compatible with and orthogonal to Categories.

I'm going to take issue with the stance that 900-line controllers are perfectly acceptable. Again, if those 900 lines are split amongst different Categories, we can talk about that. That's not what is being taught in sample code, either in forums or in the Apple documentation. I'm talking about 900 lines in one file. To me, it's worth challenging the status quo on this point.

Lastly, I'd just like to make the suggestion that perhaps I am well acquainted with Apple's recommendations and that perhaps I know them well enough to know where to bend the rules a bit.

Re: Single Responsibility Principle & iOS | The Bendyworks Blog | Bendyworks | Ruby on Rails, iOS, & Clojure Consultants | Madison, WI

Bradley Grzesiak — Fri, 07 Feb 2014 10:45:17 -0000

I was wondering when someone would take offense to that line. :)

Perhaps I used an imprecise word in "indicative." I mean to say that using `#pragma mark -` likely indicates poor code, especially when combined with the simpler `#pragma mark`. Creating a two-layer hierarchy of sections of code on top of the natural grouping inherent in methods tells me that something is begging to be extracted.

Would I ever ban `#pragma mark -` outright? Most definitely not. But I would consider why it's there very intently. I would almost never have a qualm in having one separating "object setup" (e.g. `awakeFromNib`, `viewWillAppear`, etc for a VC) from object behavior.

Re: Single Responsibility Principle & iOS | The Bendyworks Blog | Bendyworks | Ruby on Rails, iOS, & Clojure Consultants | Madison, WI

Bradley Grzesiak — Wed, 05 Feb 2014 19:59:49 -0000

Absolutely. It'll take some hammock driven development[1] to get there, but I'm sure it's possible in a "reasonable" way.

[1]: http://www.youtube.com/watc...

Re: Single Responsibility Principle & iOS | The Bendyworks Blog | Bendyworks | Ruby on Rails, iOS, & Clojure Consultants | Madison, WI

Bradley Grzesiak — Wed, 05 Feb 2014 12:57:32 -0000

Showing more of the storyboard is a bit tricky in article form. So instead, I provided a sample app with an example of using two Intention objects: https://github.com/listroph...

Re: Drowning in JavaScript

Bradley Grzesiak — Mon, 02 Dec 2013 00:49:09 -0000

Try slate.com. I just got 47 from them.

Re: Bwoken 2 Beta Released | The Bendyworks Blog | Bendyworks | Ruby on Rails, iOS, & Clojure Consultants | Madison, WI

Bradley Grzesiak — Thu, 19 Sep 2013 10:23:26 -0000

@chrischen79 I switched back and forth between Xcode 4 and Xcode 5-DP5 during development of bwoken 2, so it *should* work.

Re: The Pull Request Hack · Felix Geisendörfer

Bradley Grzesiak — Thu, 14 Mar 2013 12:03:50 -0000

Thanks for reducing my concern for your users to a 3-letter acronym. Just because you don't care about security doesn't mean it's not a thing. Simple statements like "the more active committers a project has, the harder it gets to inject malicious code" disregard reality in many cases.

I'm an ardent supporter of OSS, but I also feel that responsibility isn't something we should throw away for the sake of convenience.

Re: The Pull Request Hack · Felix Geisendörfer

Bradley Grzesiak — Thu, 14 Mar 2013 09:51:08 -0000

From a security standpoint, this is a terrible idea (modulo the strength of the "reputation" checks) for popular projects. As a project gets more and more popular, the impact of a malicious coder rises significantly alongside his/her ability to hide commits in the stream of legitimate commits. You need to remember: the code in your project is arbitrarily trusted and run (on local machines and servers) by every developer who uses it.

For smaller projects, sure... it's a great idea. For a project as popular and widespread as node-mysql? If I were using that library in particular, I'd be looking for alternatives.

Re: Programmer Interrupted

Bradley Grzesiak — Tue, 22 Jan 2013 09:44:04 -0000

I would guess a pair gets interrupted less than an individual. Societal graces about interrupting people talking and all that.

In addition, when a pair *does* get interrupted, their minds (with their different grasps of the context) will get back on task quicker through cooperation.

Don't knock it until you've tried it.

Re: Programmer Interrupted

Bradley Grzesiak — Mon, 21 Jan 2013 20:36:54 -0000

Have you tried pair programming? It's not a panacea for everyone, but I think it's a great way to write quality code without context-switching interruption. Problem is, it takes practice... you can't expect it to work wonders the first time.

Re: 2012 Rails Rumble

Bradley Grzesiak — Tue, 16 Oct 2012 13:33:55 -0000

The trick is to save a bookmark on your phone's homescreen. Then, next time you're flabbergasted at someone not having seen a particular show or movie, you can quickly enter it.

Glad you like it! :D

Re: The Markdown Mindset - The Hiltmon

Bradley Grzesiak — Sat, 25 Feb 2012 13:31:05 -0000

Markdown (and other text formats) also work really well natively with source code management tools (e.g., git). Huge win there.

Re: Dear business people, an iOS app actually takes a lot of work!

Bradley Grzesiak — Tue, 31 Jan 2012 13:16:45 -0000

Of course not. You seem to be missing the point that, taken as a whole, I agree with this blog post.

Re: Dear business people, an iOS app actually takes a lot of work!

Bradley Grzesiak — Tue, 31 Jan 2012 13:08:49 -0000

Honestly, I do think I agree with the entire post except for the aforementioned "Tightly integrated code" part. And code reuse is just a fraction of what I mean by "extremely well structured." Correctly implementing MVC, using notifications properly, etc all play into writing "good iOS code..." a talent many developers lack through inexperience or otherwise.

Re: Dear business people, an iOS app actually takes a lot of work!

Bradley Grzesiak — Tue, 31 Jan 2012 12:07:56 -0000

Good post, but I have to disagree with the "Tightly integrated code" part. I believe extremely well structured code can significantly reduce code complexity. The bar to get to "extremely well structured," however, seems to be much higher than many developers can reach.

Re: Once Again, Twitter Drops Ruby for Java

Bradley Grzesiak — Mon, 11 Apr 2011 21:29:04 -0000

Rails *is* fast, reliable, and scalable. Twitter dropping ruby is anecdotal evidence in the face of bleeding edge scaling needs that no one else in the world is experiencing.

Re: http://blog.10gen.com/post/3623456584

Bradley Grzesiak — Thu, 31 Mar 2011 12:42:38 -0000

Having an office less than a block away from a protest that's making international headlines gave us a unique opportunity: use our technology prowess to experience live events in a new way. So what did we do? We wrote a site using Rails, WebSockets, Heroku, MongoDB, and the Twitter Streaming API. In 6 hours.

Blog post: http://bendyworks.com/news/...

Actual site: http://www.voicerally.com

Re: http://bendyworks.com/geekville/articles/2011/2/from-0-to-1-million-in-6-hours

Bradley Grzesiak — Tue, 22 Feb 2011 12:32:41 -0000

Heh... That, my friend, is a hack suitable for its own blog post. Short answer: EventMachine is running on a Heroku console.

Re: Fetching source index for http://rubygems.org/

Bradley Grzesiak — Thu, 13 Jan 2011 10:42:45 -0000

What about murder for distribution? https://github.com/lg/murder

I'd really like a way for my business to have a local (no, seriously, like on-site) rubygems repository that syncs to an upstream server, which then syncs to a master server. Frankly, this is really sounding like the DNS system.