Disqus - Latest Comments for technoweenie

Re: Versioning Large Files with Git LFS

technoweenie — Mon, 31 Aug 2015 13:32:37 -0000

Hey, thanks for writing about Git LFS. It's helpful to see the perspective of a new user trying it out. Also, there are some really cool improvements to the "fetch" command being worked on: https://github.com/github/g...

Re: Towards a production quality open source Git LFS server

technoweenie — Thu, 13 Aug 2015 13:53:25 -0000

Hey, feel free to ask us questions at https://github.com/github/g.... Also, the test server is not meant for production use.

Re: On Rails, Sinatra, and picking the right tool for the job

technoweenie — Thu, 13 Sep 2012 11:31:29 -0000

We approach it very similarly at GitHub. The API is made up of 30 or so Sinatra Apps (that are bundled into a single process), and it works very well. The DSL maps very closely to the actual request. I like not having to deal with conventions designed for a web site.

But, we've also migrated internal Sinatra web apps to Rails apps. At a certain point, it just made sense to use a framework with more of the structure and tools that people were used to.

For what it's worth, both our Rails app and our Sinatra/Rack endpoints get merged into a single unicorn. You can actually share models across an App and an API at the same time. Not to say that the code is amazing or anything... It's more a slow evolution of a 4 year old code base :)

Re: The HTTP OPTIONS method | zacstewart.com

technoweenie — Sat, 14 Apr 2012 16:58:16 -0000

That's interesting. I like how you're mixing JSON Schema with verbs in the output. I've experimented with similar ideas for the GitHub API: https://github.com/technowe....

Re: Of GitHub and Pull Requests (and comics)

technoweenie — Wed, 11 Apr 2012 11:24:25 -0000

I have a lot of tiny (and some not so tiny) projects, and I miss pull requests all the time. So, at least you got polite replies :)

As a maintainer, I love seeing code from random people. Depending on the size of the project, there can be lots of considerations in merging patches though. One thing I've been trying over the last year is being very open about sharing collaborator access. If someone sends me a couple good patches, I offer to give access.

Good projects should have clear guidelines for accepting submissions somewhere. The README is a great place to put guidelines like styleguides, requirements (unit testing), documentation or compiled code policies, etc.

As a contributor, I love that GitHub takes some power from the maintainer. If you ignore or reject my patch, I can just fork and carry on. Though I'd suggest keeping the master branch clean and putting your patches on a separate branch. This way you can update the master from the source without conflicts.

Re: Feature branch code reviews

technoweenie — Wed, 19 Jan 2011 18:47:16 -0000

At GitHub we use CI Joe.

Re: Lamson (Python SMTP Server) Error - BeenAsked.com

technoweenie — Tue, 09 Nov 2010 13:05:16 -0000

This is due to an API breaking change in a newer version of Lockfile. There's a Lamson ticket open for this already, with a hotfix you can make: http://support.lamsonprojec... . I'm sure it'll get fixed in Lamson really soon though.

Re: Superfeedr : JSON PubSubHubbub Notifications

technoweenie — Mon, 08 Nov 2010 13:46:57 -0000

I'm not sure where the spec mentions you _have_ to use atom or rss. It seems pretty open about all that. We don't have custom types defined yet, but it's something I'd like to do at some point.

Re: Superfeedr : JSON PubSubHubbub Notifications

technoweenie — Mon, 08 Nov 2010 12:07:24 -0000

This is good stuff. Have you thought about giving it a more descriptive mime type other than application/json? You weren't sending just XML before, you were sending application/atom+xml. Applications should define more custom mime types.

For instance, instead of getting GitHub commits as application/atom+xml or your json version of atom, I should be able to ask for application/vnd.gh-commit+json.

This of course depends on us defining proper mime types too. I'm just suggesting that you leave that window of possibility open.

Re: Be awesome: write your .gemspec yourself - Jeff Kreeftmeijer

technoweenie — Wed, 20 Oct 2010 10:09:45 -0000

I use rakegem (http://github.com/mojombo/r... for everything now. It does a little bit of generation in your otherwise-static gemspecs. The rake task has some code for updating the gem version from a VERSION constant and updating the file list from whatever is checked into git.

Re: Mikahail's memory of john locke by bamboogrowsontheisland

technoweenie — Wed, 31 Mar 2010 19:58:15 -0000

I think you're overthinking things a bit. When Mikhail detected the plane crash, Ben had him get as much info on the passengers as possible. That's how he knew their names already. He was just being snarky to Kate for doubting him.

Maybe he was just destined to lose his eye in any dimension. Poor guy.

Re: Tornado on Twisted

technoweenie — Tue, 15 Sep 2009 03:26:51 -0000

YO TORNADO I KNOW YOU JUST GOT RELEASED AND ALL AND IMMA LET U FINISH... BUT TWISTED WAS THE BEST EVENT DRIVEN NETWORKING ENGINE OF ALL TIME

Re: Receiving Email with Rails

technoweenie — Fri, 24 Apr 2009 03:33:55 -0000

Piping emails to a ruby process can present some scaling issues. Each email is basically another ruby process that loads rubygems, tmail, mms2r, etc. It's probably better to just have postfix dump emails to a maildir and have tmail read them in a little ruby daemon: http://tmail.rubyforge.org/... . I handled all of our email processing fine with ruby pipes for awhile. But when I moved to our current host, they were quick to suggest using a maildir.

I didn't know about mms2r, but I'll take a look at that. I think I parse the mail parts manually with tmail right now, blah :)

Re: semantic art - ruby - Using default_scope to recreate acts_as_paranoid

technoweenie — Mon, 23 Mar 2009 10:02:49 -0000

Awesome, now I don't have to worry about updating my plugin for Rails 2.3 :) Though I wish you'd have submitted it as a patch so I could update acts_as_paranoid for all the people that ask me about it.

The problem with the plugin is now how complex the code is. The original plugin wasn't that complex without the default scope. The problem is that the normal looking code is doing unexpected things. It's probably fine for cookie cutter apps though.

You might also run into some side effects. A blog Entry model having many comments set to a dependency of :delete_all may unexpectedly be deleted and unrecoverable if the Entry is restored. At some point you really need after_hide and after_restore callbacks separate from after_destroy. Weird cases like this keep me from being able to use acts_as_paranoid. Plus, I also don't mind being a little more explicit in my code.

Re: Database Versioning

technoweenie — Mon, 02 Mar 2009 23:58:34 -0000

I migrate my databases in development mode incrementally and only ever do a full schema load when bootstrapping new installations. Migrations are tested on every developer's machine and staging before making it to the live server.

Re: Database Versioning

technoweenie — Mon, 02 Mar 2009 23:43:20 -0000

Can you rename a column with auto_migrations? I believe it's effectively the same as Datamapper's auto_upgrade feature.

Re: Database Versioning

technoweenie — Mon, 02 Mar 2009 15:54:33 -0000

I'm not sure I agree with most of your points. First, migrations were never meant to access your application models. It is too easy to run into migrations that access old models and whatnot. If you did need to access the model, you'd create a new ActiveRecord class inside the migration class and sidestep those problems. Sure, ActiveRecord would benefit greatly for a great raw SQL interface like SQL... but that's a whole other discussion (curse you Twitter, for keeping Nick Kallen too busy to work on ActiveRelation). Also, why would you even run hundreds of migrations when bootstrapping an app? I always run db:schema:load, and a custom task to import essential data.

I'm not really sure that generating a schema yml is any better than generating a ruby file. I've found that the problems with schema differences between commits has to do with git branches, and differing column orders in everyone's development databases. Also, git branching seems to be the cause of consistency issues. Someone adds a field in a branch, commits. Then goes to master and does something and inadvertently pushes their modified schema to the master branch. It happens quite often, and is a good argument against my practice of running `rake db:schema:load`. We may need to be able to branch databases as well. Branch, make your updates, merge to master, and run the migrations fresh against the master dev database.

I'm curious how you'd propose to handle the case where a migration in master and one in a feature branch that's ready for merging both attempt to migrate from the same version? This was the problem we had with the old counter-based migration numbers that ActiveRecord used to have.