Well, that sucks! Fortunately, the fix is a quick search and replace. You just have to change the following:
| mt:authorevents | => | mt:ActionStreams |
| mt:eventdate | => | mt:StreamActionDate |
| mt:event | => | mt:StreamAction |
| mt:eventmodifieddate | => | mt:StreamActionModifiedDate |
The first step to really working with Catalyst
is to venture out and write your own components. Whether it is a view
or model they share the same common ancestor, which is
Catalyst::Component. Catalyst::Component is an important part of
Catalyst, as it sets up the model, view or controller object. Catalyst
will handle instantiation (calling ->new) as well as calling a setup
method called COMPONENT. While both of these methods can be overridden, it is better to override COMPONENT if you need to execute code at instantiation time.
Important Note: whatever object is returned from COMPONENT, Catalyst treats as the object for that model or view. This means that if you return a different object from an overridden COMPONENT method, that is what you will get back from calling $c->model("Foo");.
More on that further down, for now a very simple model class that has default configuration:
package MyApp::Model::Foo;
use warnings;
use strict;
# You must inherit from Catalyst::Model, which in turn inherits from Catalyst::Component
use base qw/Catalyst::Model Catalyst::Accessor::Fast/;
# Make an accessor for 'foo'. Inheriting from Catalyst::Accessor::Fast lets us easily do that
__PACKAGE__->mk_accessors('foo');
# All Catalyst components have ->config available to them. This is merged in with the application-level
# configuration after instantiation.
__PACKAGE__->config(
'foo' => 'default foo value'
);
1;
That's it, that is all that is there for your model to exist. Catalyst (and friends) handle everything else. If you want to get at the 'foo' variable, you simply have to use the accessor:
$c->model("Foo")->foo; # returns 'default foo value';
$c->model("Foo")->foo('new value');
It's important to remember that while Catalyst does some abstraction of the mundane code, it is still just perl. That means that if you add a method to the Foo model above, it will be available via $c->model("Foo"), which as discussed above, is simply an instantiation of MyApp::Model::Foo.
So, to change this, override the COMPONENT method:
package MyApp::Model::Foo;
use base 'Catalyst::Model';
use External::Module;
sub COMPONENT {
my ( $self ) = @_;
return External::Module->new;
}
Now, all calls to $c->model("Foo") return the
instant of External::Module. Use this wisely, and also sparingly. If
you find yourself binding to external modules, it is highly recommended
to use Catalyst::Model::Adaptor to do it, rather than writing the code yourself.
http://static.cartionary.com/images/{uuid}/{mutations}.{ext}For now, we just serve images, so that part is easy to deal with. The UUID is the unique identifier that we use to store the image and {mutations} is any series of programmatic mutations.
varnishadm -T :6082 url.purge {uuid}Done! All requests for that UUID will end up as a 404.
The main gist is properly identifying just what type of person you are working with, and to a more significant degree, what type of person you are (which is variable). I have my own thoughts on the specifics that he lists that I'll likely write up later, but for now just reading it is a good start to continue my current thoughts.
I think that it equally important to understand the tools you are using. It seems a lot of people use a specific tool because they don't really think about other tools. If a problem looks like a nail, they use a hammer. While I hate metaphors when they're not necessary, I think using the nail/hammer metaphor does work for this case.
What ends up happening is the, "When all you have is a hammer, every problem looks like a nail." syndrome. Conversely, if you have a vast array of tools at your disposal, you are going to over-complicate problems. There is a very important balance that must be maintained.
If I had to pick over-engineering a problem, versus simply driving a nail in a plank of wood and calling it a deck, I'd over-engineer it every time. This is coming from years of experience, and several contracts that seemed to extend in two-week intervals where I was expecting to find another gig every two weeks. One of those went for 2 years, adding two-weeks worth of "enhancements". It was all hammer and planks of wood. Absolutely terrible.
The reason why I'm writing this is because a discussion popped up where I expressed my confusion in people using plain vanilla mod_perl, then being frustrated with testability and other nuances. Someone pointed out that mod_perl is a perl runtime inside of Apache that gives you programmatic hooks into Apache.
Fantastic. However, that doesn't enter into what my point was. People use mod_perl because that is the only tool they know. I believe this is the case with most PHP-based engineering shops. They use PHP because that is the tool they, or the managers, know.
The problem with this mentality is that by not knowing the tools, you are doomed to work within the confines of what you know. While the skillset and knowledge may evolve, it won't have a renaissance or giant evolutionary leap.
This is the key reason for learning other toolsets and libraries that are available. It isn't about jumping to trendy and shiny technology, it is about defining your own capabilities in relative scope to what other technology is around.
It's very easy to spot this type of individual, which I view as a blessing. If a person ever argues against a tool (or rather, using a tool in place of something that they know) you can count on them being very limited in their ability to accurately scope and understand a problem. They will mutate the problem to be solved with the tools at their disposal.
In context of Zed's C2I2 hypothesis, I've been struggling to really distinguish between a collaborator and an implementer. They were very much the same in my mind. Thinking about the usage and understanding of tools has helped clear this up for me.
A collaborator doesn't know the details of the tools. They follow cookbook recipes. Contrast that to an implementer, who still follows cookbook recipes but understands the tools that are being used.
The inventor, of course, usually is the one building the tools. If a tool doesn't fit an implementers agenda, they'll either move on or smash at it until it works. An inventor will go in and fix the tool. A collaborator will be that guy on the mailing list you wish would go away, and probably be the first in line to argue against other tools they've never used.
]]>The problem with that thought is that I did have something to lose. And lose it I did. I lost my belief that Microsoft couldn't produce a program that is worse than any other alternative.
I don't like to unnecessarily hate on Microsoft, but I find their products to be absolutely terrible when compared with sufficiently advanced alternatives. In the case of Windows Live Writer, there is no alternative.
A few folks have pointed out Mars Edit and other offerings (on OS X, as that is my platform of choice currently) but they really aren't as good as Live Writer. Even under Linux I couldn't find anything that is just better than Live Writer.
It still isn't perfect, but it works extremely well. Now my only hope is that Microsoft will lose something... the irritating need to bundle a staggeringly large amount of irrelevant software with Live Writer. Until they do that, I don't think I can recommend Live Writer to people who won't just blindly click "Continue" without seeing what other crap they're installing. If you do read before clicking, definitely check it out.
It seems to be working fantastically with Movable Type 4, but I still need to figure out how to manage static pages.
]]>