Disqus - Latest Comments for zvoase

Re: My Django Project Conventions

zvoase — Thu, 12 Feb 2009 08:12:52 -0000

Yeah, sorry about the 'supposed' bit - it's just that the default template loaders include an app loader but not a project loader. It probably should have been 'the default is to have them at app-level', or something...anyways.

I think this discussion is one that should be moved to the mailing list. It would be nice to see some of this built in to the Django core - if not as a contrib app.

Re: My Django Project Conventions

zvoase — Thu, 12 Feb 2009 08:09:31 -0000

They're really just two sides of the same coin, I'd say. The only problem is having to set DJANGO_SETTINGS_MODULE, but I guess it's no different from setting the mode.

Re: My Django Project Conventions

zvoase — Wed, 11 Feb 2009 21:33:11 -0000

But I'm probably going to refactor this all out into a separate re-usable app anyway, so...

Re: My Django Project Conventions

zvoase — Wed, 11 Feb 2009 08:17:27 -0000

The thing about the sludge in __init__.py is that it's completely separate from the rest of your code. You can just stick it in there and never see it again, so it's slightly more bearable. As RockHoward has stated, you can have several different 'modes', which is actually comparable to the way Rails does things.

Re: My Django Project Conventions

zvoase — Tue, 10 Feb 2009 23:20:08 -0000

I'm considering sticking all this stuff in a reusable app soon anyway, I'll notify you when I do :) Thanks

Re: Call the Super NOW! This apartment is flooding quickly!

zvoase — Tue, 10 Feb 2009 13:15:02 -0000

I like the dark-on-light actually :)

Re: Digitol Musings

zvoase — Tue, 10 Feb 2009 12:20:39 -0000

I think the answer is (1). It's DeMorgan's theory of logic, which is as follows:

(NOT A) OR (NOT B) is *always* equivalent to NOT (A AND B) -- (i)
(NOT A) AND (NOT B) is *always* equivalent to NOT (A OR B) -- (ii)

I believe that a statement that always evaluates to truth is also known as a 'tautology'.

Am I passing yet? I'd love to see more bits of this class.

Re: http://ionrock.org/blog/2008/12/17/Rails_Got_Racked_

zvoase — Fri, 30 Jan 2009 13:11:25 -0000

I do get what you mean. I think it's more of a result of Ruby's syntax than anything else. BTW, I'm a massive Pythonista and I still use it regularly. WSGI FTW!!!
Plus, I've only been using Ruby for 2 days. I've read two books so far, but I'm still a little inexperienced. :D

Re: http://ionrock.org/blog/2008/12/17/Rails_Got_Racked_

zvoase — Fri, 30 Jan 2009 11:45:10 -0000

Actually, there is no difference between functions and methods in Ruby. Functions defined at the top-level are just methods of a 'main' object – hence the discrimination (present in Python) is not present in Ruby.

Also, about adding a __call__ attribute to a Python object, you could just add a 'call' attribute to a Ruby class, and it would work identically to the method object.

Re: http://ionrock.org/blog/2008/12/17/Rails_Got_Racked_

zvoase — Fri, 30 Jan 2009 06:07:08 -0000

Ruby does support the passing around of methods as first-class citizens, it's just slightly different to the way Python does it. Ruby's idea of sending functions around is based on the idea of Inversion of Control. But what you might have is something like this:

def myapp(environment)
do_something_here
yield response_data
end

Then the WSGI implementation would receive the request, turn it into an Environment object (or whatever), and call myapp with a block representing 'start_response'.

You can also pass functions around quite easily. First, you have to get the method object like this:

method_object = method :method_name

You can then use method_object.call(arg1, arg2) to call the method. So that's a (slightly explicit) way of dealing with first-class functions. Also, you can create block objects using lambda:

block = lambda { |arg1, arg2| do_something_here }

And then call them using block.call. In addition, you can make block passing and receiving explicit via the ampersand prefix:

method(arg1, arg2, &block) # calls method with block as the block

def method(arg1, arg2, &block) # 'block' variable now holds the block.
do_something
end

So there are ways, they're just not as obvious as in Python.

Re: A Programmer's Apology

zvoase — Fri, 30 Jan 2009 05:50:59 -0000

I'm going to learn C soon actually; more because of the fact that it tends to be the 'Lowest Common Denominator' when it comes to UNIX programming (and I'm almost definitely going to stick to UNIX). It's also blazingly fast, so if I need to squeeze speed out of something I can use a small C program to do so. As well as this, a lot of languages support C extensions (for speed), so for many reasons it's a good language to learn, and I shall be doing so shortly.

Re: A Programmer's Apology

zvoase — Fri, 30 Jan 2009 05:49:13 -0000

That's true, but I find new languages pretty easy to pick up. I don't know why, but I think each language (and, by extension, each implementation of each language) offers different benefits; for example, Erlang was designed for large-scale message passing between actors, so if I were developing a VoIP program I would use Erlang. Likewise, Python's good for web apps, text processing, bioinformatics, etc.

I am learning Ruby before Rails though. I actually really like it as a language, and what's more I can now list Ruby as a language I'm familiar with. I understand how Rails has a bunch of extensions to Ruby; but most of this is in a sub-module called ActiveSupport, and it's possible to just use AS alongside any programs I want to write using those features.

It's also important to remember that I'm not just *forgetting* Python. I'm adding more strings to my bow, not replacing what I've currently got. I'll still have a love affair with Python for many years; I appreciate its explicitness, in contrast to Ruby's Perlesque implicitness (Ruby is a little bit write-only). I also think the community is great.

Re: A Programmer's Apology

zvoase — Fri, 30 Jan 2009 05:38:47 -0000

Not really. I'm increasing the number of tools I'm familiar with, so that I have several strings to my bow and therefore, when a problem does present itself, I'll be prepared.

Re: A Programmer's Apology

zvoase — Tue, 27 Jan 2009 09:49:06 -0000

OK, most of the comments thus far have stressed pretty much the same thing: that sometimes the programmer working on a system won't be able to use the best tool, as we have deadlines and limited capabilities. I understand this, and when weighing up 'the best tool for the job' (I probably should have mentioned this in the post) it's important to include all aspects which might make something the best choice—including programmer familiarity and ability.
Personally, I find it quite easy to quickly adapt to different styles of development, so this post (which is quite specific to me, because I can't really talk about anyone else) is kind of personal. For other people who find they are only comfortable with a smaller subset of languages/frameworks, then sometimes the dogma is justified. But when you *do*, actually, have a choice, then you should consider it rationally before jumping to a conclusion.
Also, it's important not to take on jobs which you might not be able to do. Note that, by inability, I'm not just talking about skill—time, financial state and personal issues all count towards making you unable to do something. That's probably just as dangerous as doing something the wrong way.

Re: dm fail! - dm lexia did that rash clear up btw?

zvoase — Tue, 23 Dec 2008 20:40:00 -0000

Well did it?

Re: I Have a Dream. In Common Lisp and Twitter.

zvoase — Wed, 12 Nov 2008 17:14:57 -0000

I actually really *love* common lisp's syntax. Like, really. I don't quite know why, there's just a beautiful aesthetic to it.
And Erlang's nice, but quite slow. I wish they still sold Lisp machines. They'd be hella fast right now.