Disqus - Latest Comments for jasonrudolph

Re: ClojureScript Experience Report — Resources

Jason Rudolph — Sun, 25 Nov 2012 18:47:56 -0000

You definitely want to be wary of client-side code. A malicious user might alter the client-side code in an attempt to access data that he's not authorized to access. Or, he might alter client-side code in an attempt to corrupt or destroy data.
To protect against these scenarios, One Rep Max uses the user's MongoHQ API key in order to access the user's data stored at mongohq.com. When One Rep Max launches, it prompts the user to enter his API key. One Rep Max (running locally in the user's browser) uses that key to make authenticated requests to the MongoHQ API. Using that key, One Rep Max can access and manipulate the data in that specific user's MongoHQ database, but it cannot access the databases belonging to any other users. Therefore, we don't have to worry about client-side code accessing data that it is not authorized to access; MongoHQ's built-in security gives us the protection we need. Of course, the user could still alter the client-side code to corrupt or destroy data, but he would only be corrupting or destroying his *own* data, so there isn't much incentive for that form of malice. ;-)

Re: ClojureScript: 4 Things That Might Worry You, but Shouldn't

Jason Rudolph — Sat, 15 Sep 2012 10:19:00 -0000

This is a good point. It's funny though: I run into this so rarely that I wasn't even sure that it still happened. I had to go intentionally insert an syntax error in my code to verify that this behavior still exists.

I think there are two primary reasons why I had forgotten about this issue:

1. My editor's syntax highlighting alerts me to many potential syntax errors. That helps me make fewer syntax errors.

2. I typically make small changes, and I then verify that those changes work. If I've introduced a syntax error, I know the general area where I need to look.

While I'd like to see the compiler's error reporting improved, I rarely find it to be a significant problem.

Re: ClojureScript: 4 Things That Might Worry You, but Shouldn't

Jason Rudolph — Fri, 14 Sep 2012 10:12:16 -0000

I used ClojureScript for two reasons:

1. I wanted to take a deeper dive into Clojure, and I enjoy exploring a language by using it to scratch an itch. In my case, I wanted to build a mobile app for tracking my workout data. I suppose I could have built it with something like Compojure+JavaScript, but I wanted to maximize my time writing Clojure. By choosing ClojureScript, I was able to write 100% of the application logic in Clojure, which meant that I was able to spend more time learning/practicing Clojure.

2. I wanted to build a single-page app where 100% of the application code runs inside the browser. Most of my previous client-side experience was similar to what you describe (i.e., a “little bit of front-end interactivity”). With this project, I was embarking on something on a much larger scale. It has no server-side code at all; it’s all client-side code. To support that effort, I wanted a good mechanism for organizing a larger code base (e.g., Clojure namespaces).

With those motivations, I chose ClojureScript, and I’m happy that I did so.

If I wanted to add just a “little bit of front-end interactivity” to a web app, I probably wouldn’t use ClojureScript today. It’s not easy enough (yet) to just drop it into a web project. In this case, the client-side code is a “condiment.” ;-) And currently, ClojureScript feels more like a “main dish”—in my opinion, a fairly tasty one.

Re: Bitwise operations in Ruby, and an example application to testing with Rspec

Jason Rudolph — Mon, 20 Aug 2012 18:42:04 -0000

I agree with DGM and Matt.

The assertion represents a testing anti-pattern sometimes referred to as the "ugly mirror".

Because the test code essentially mirrors the implementation code, it's incredibly easy for both of them to be wrong, and thus the tests wrongly pass (i.e., we end up with a false sense of correctness).

I appreciate the desire to avoid having to manually write a separate assertion for each and every combination. This would get old very quickly:


     it "can not be activated if not persisted and status is new" ...

     it "can not be activated if not persisted and status is suspended" ...

     it "can be activated if not persisted and status is new" ...

So, let's take into account these two motivations:

1. We want to avoid hand writing a bunch of boilerplate specs.

2. We want to avoid the ugly mirror (i.e., we want to use literal values in our assertions, as opposed to duplicating the implementation algorithm inside the assertions).

With these motivations in mind, I'll offer the following alternative: https://gist.github.com/338...

And, I'll try pasting the code inline here. Fingers crossed that it renders correctly. ;-)

# [ activable?, persisted?, new?,  suspended? ]
# =============================================
combinations = [
  [ false,      false,      false, false      ],
  [ false,      false,      true,  false      ],
  [ false,      false,      false, true       ],
  [ false,      true,       false, false      ],
  [ true,       true,       true,  false      ],
  # and the remaining possible combinations ...
]

combinations.each do |activable, persisted, _new, suspended|
  license.stub(:persisted?).and_return(persisted)
  license.stub(:status_new?).and_return(_new)
  license.stub(:status_suspended?).and_return(suspended)
  
  license.activable?.should eq(activable)
end

Re: Episode #288: Pruning Your Branches

Jason Rudolph — Sat, 14 Jul 2012 15:35:00 -0000

Good stuff!

As a bonus, recent versions of Git have added some usability improvements to make these tasks easier and more intuitive.

=== Fetch and Prune in One Step ===

Prior to Git 1.6.6, you needed two steps into order to fetch and prune:

git fetch
git remote prune your_remote

As of Git 1.6.6, you can actually combine fetching and pruning in a single command.

git fetch --prune

=== Improved Syntax for Deleting Remote Branches ===

I would argue that the original syntax is odd and a bit unintuitive for deleting remote branches:

git push your_remote :branch_name

Who thought ":" was a good indicator for "delete"? ;-)

As of Git 1.7.0, you can use this alternative syntax to delete remote branches:

git push your_remote --delete branch_name

Re: :jasonrudolph => :blog >> Programming Achievements: How to Level Up as a Developer

Jason Rudolph — Fri, 19 Aug 2011 17:27:39 -0000

I wrote a quick script to fetch all the forks and identify any new content. You can see the results here:

https://gist.github.com/115...

Re: :jasonrudolph => :blog >> Programming Achievements: How to Level Up as a Developer

Jason Rudolph — Thu, 11 Aug 2011 18:19:15 -0000

Interesting. Thanks for pointing out that matrix. I'm glad to see that SICP and Forth land you in the top tier of the matrix. ;-)

Re: :jasonrudolph => :blog >> Programming Achievements: How to Level Up as a Developer

Jason Rudolph — Thu, 11 Aug 2011 18:18:50 -0000

> Even the most ambitious of individuals will find achieving all of this unrealistic while maintaing good balance between career and family.

Justin (below) had a similar concern. Please see my reply: http://jasonrudolph.com/blo...

Re: :jasonrudolph => :blog >> Programming Achievements: How to Level Up as a Developer

Jason Rudolph — Thu, 11 Aug 2011 18:17:53 -0000

That's a very personal decision. Don't let anyone else make it for you.

What do *you* *want* to do? (Note the emphasis on "you." Note the emphasis on "want.")

Re: :jasonrudolph => :blog >> Programming Achievements: How to Level Up as a Developer

Jason Rudolph — Thu, 11 Aug 2011 18:17:11 -0000

> Don't think this is helpful.

I'll make sure you get a refund then. ;-)

> Yeah, if you do all that stuff, it will probably make you a better developer. But you've basically staked out a whole career here.

Perhaps. But as I responded to Justin in the thread below, I have some good news: each *individual* achievement benefits you. ;-) If you only do one of them, you benefit from that one. If you're worried about the time commitment, pick one of the smaller ones. (For example, you can prepare and present a lightning talk in much less time than it takes to prepare and deliver a training course.)

Then, if you like, you can start on another one and pursue its benefits.

This is not a process wherein you work for thirty years and get zero reward until the very end. You reap benefits every step of the way.

Re: :jasonrudolph => :blog >> Programming Achievements: How to Level Up as a Developer

Jason Rudolph — Thu, 11 Aug 2011 18:16:02 -0000

We agree on at least one thing: if you ignore the goals of your project and you focus only on the tools, you are destined to fail.

Of all the metaphors you could have chosen, it's funny that you chose carpentry. I'm sure you're familiar with the saying: "If all you have is a hammer, everything looks like a nail." (Maslow's Hammer: http://en.wikipedia.org/wik...

You argue that "to be a good programmer you must learn to program effectively." I agree. Can a carpenter be effective if he only knows how to use a hammer? Of course not. The same goes for software development: if you never explore other approaches to solving problems, you won't be as effective as you could be.

Re: Refactotum

Jason Rudolph — Thu, 11 Aug 2011 07:31:30 -0000

Thanks for the heads up. Those links are fixed now.

Re: :jasonrudolph => :blog >> Programming Achievements: How to Level Up as a Developer

Jason Rudolph — Wed, 10 Aug 2011 18:22:19 -0000

> This is too much for one person to do it all and still have time to build business solutions for their employers.

Perhaps. But I have some good news: each *individual* achievement benefits you. ;-) If you only do one of them, you benefit from that one. And then, if you like, you can start on another one and pursue its benefits.

> Some items, like writing a book or creating an open-source project are easier said than done and may not be realistic for most programmers.

Isn't everything is easier said than done? You can do anything if you put your mind to it.

> Still, I plan on picking a couple of these items and using them to increase my knowledge.

Rock on!

> Might I also suggest another item: Learn and understand how a popular run-time environment really works under the hood (i.e. CLI/CLR or JVM).

I like it. Any thoughts on how to make that achievement measurable/observable? Perhaps you could combine this task with some aspect of teaching? For example, present a talk at a local user group (or to a group of coworkers) explaining how a popular runtime environment works under the hood.

Re: :jasonrudolph => :blog >> Programming Achievements: How to Level Up as a Developer

Jason Rudolph — Wed, 10 Aug 2011 18:04:25 -0000

I agree with the importance of those two goals: building the right thing and building it well.

* If you deliver a beautifully-crafted system, but it doesn't satisfy the project's objectives, you're doing it wrong. (Actually, good developers do more than deliver what was required; they seek out the *motivation* for those requirements.)
* And as you noted, if you skimp on quality, you're doing it wrong.

Those goals are more than important; they're non-negotiable. It's not that the post "misses" these goals, it's that I consider these goals to be implicit.

Re: :jasonrudolph => :blog >> Programming Achievements: How to Level Up as a Developer

Jason Rudolph — Wed, 10 Aug 2011 17:23:55 -0000

Good question. :-)

I'm getting closer every week. I decided back in April that I wanted to run a 5-minute mile. At that point, I ran at 6:29 mile.

Since then, it's been several months of hill sprints, intervals, long-distance runs on Sunday mornings, track meets, etc. Last week I ran a 5:40 mile. (Progress!) It's been hard work, but I'm getting closer to my goal every week.

It's also been *fun* to pursue this goal. The same thing goes for programming achievements: don't forget to enjoy the pursuit.

Re: :jasonrudolph => :blog >> Programming Achievements: How to Level Up as a Developer

Jason Rudolph — Tue, 09 Aug 2011 20:11:19 -0000

I've completed many of these achievements, but I definitely have not completed all of them. Each one that I have completed has been a positive learning experience though, and I look forward to learning from the one I'm working on now and the ones I'll pursue in the future.

Re: :jasonrudolph => :blog >> Programming Achievements: How to Level Up as a Developer

Jason Rudolph — Tue, 09 Aug 2011 20:00:39 -0000

Thanks, Mike. Glad you enjoyed the post.

> Have you ever had that experience of looking at some code you did a long time ago and being amazed at your own cleverness?

Definitely. And it's usually not "amazed" in the sense that I am impressed by the code; it's usually "amazed" in the sense that I can now see a cleaner approach to solving the problem at hand. As a guideline, I try to avoid *cleverness*, as it is often at odds with intuitiveness and readability.

Re: Blog | Why I still prefer Prototype to jQuery | Relevance

Jason Rudolph — Sun, 16 Jan 2011 10:33:49 -0000

This is fixed now. Thanks for alerting us to this problem.

Re: Testing Anti-Patterns: Overspecification

Jason Rudolph — Tue, 25 May 2010 20:29:39 -0000

Thanks for point this out. It's fixed now. Sorry for the trouble.

Re: Testing Anti-Patterns: Overspecification

Jason Rudolph — Tue, 25 May 2010 20:28:51 -0000

Zoinks! Sorry about that guys.

And you're right, Paul; that irony is definitely not lost on me. It's fixed, and I now have tests in place to detect and prevent this error in the future. ;-)

Re: Astrails Importing Mephisto comments into Disqus

Jason Rudolph — Fri, 02 Apr 2010 16:35:30 -0000

Thanks for this! I had to make a few tweaks for the latest rest-client gem and the latest disqus API. You can see those tweaks on this fork: http://gist.github.com/353645

Re: RunCodeRun

Jason Rudolph — Sun, 15 Nov 2009 17:25:51 -0000

Glad we could help.

Regarding the more complex build setups you mentioned: we currently have customers using RunCodeRun with multiple databases and customers using RunCodeRun with Sphinx. Such setups usually involve a support request to answer a question or offer some guidance, but we're happy to help.

Thanks for using RunCodeRun.

Re: Testing Anti-Patterns: Overspecification

Jason Rudolph — Sun, 08 Nov 2009 16:52:14 -0000

@levsa I'd usually define #create_product in my collection of factories used for generating valid test objects. For Ruby and Rails projects, I prefer factory_girl. Prior to the existence of factory_girl, I used to roll my own factories, so you could certainly do that as well.

I hope this helps.

Cheers,
Jason

Re: Now Supporting Campfire Notifications

Jason Rudolph — Wed, 19 Aug 2009 21:26:52 -0000

Thanks for pointing out this confusion. We'll be sure to update the UI soon. In the meantime, we've updated the screenshot above to show our real world settings (so that folks can see to use the room name instead of the room number).

Re: Git Up! 10 Reasons to Upgrade Your Old Git Installation

Jason Rudolph — Sat, 20 Jun 2009 15:40:39 -0000

@gitster - Thanks for the clarification! I've updated the post accordingly.