After some research Heroku and Amazon EC2 seemed to be the best fit. During development the app was hosted on Heroku using it’s free tier for one dyno. As always, setup was very easy and all external services, like the database, memcached, Blitz.io and Papertrail were connected in no time.

But there are two “problems” with heroku:

1. I don’t have complete control over the server(s). This is a questionable point since Heroku provides a platform rather than just an infrastructure, so one might argue that not caring about the server(s) is actually a good thing. But I rather have full control over everything.

2. The price. Heroku’s free dyno is awesome, especially for development to get the app up and running very quickly. But once you actually need to scale, it becomes really expensive really fast.

The second argument is probably the most interesting one for most business owners and quite a few people already wrote about it in the past. So it’s clear that Heroku is more expensive than EC2, which makes sense since Heroku runs on top of EC2. But is Heroku actually worth the money?

Well, if you don’t have any experience with server administration it might be. But usually at least one team member has some knowledge. You could also hire a dev op.

I did some testing and used Blitz.io to get some traffic on the servers and it became clear very quickly that Heroku can’t cope with EC2. Even one micro instance (free for the first year!) was faster and could cope with more traffic than a Heroku dyno (using specific settings for nginx and unicorn, which aren’t changable for Heroku of course). Even two dynos were still performing worse than one micro instance in some cases, because of Heroku’s queuing, and yes the app used Unicorn to have a higher concurrency for each dyno. The EC2 instance didn’t had that issue.

There’s also another trap: Most people only calculate the cost of the dynos. But all the other things you might need, like database, memcached, logging, redis, mail and so on are pretty expensive as well! Compare Heroku’s database pricing with Amazon RDS and make sure you compare the storage size as well. Amazon really cuts it here!

Bottom line: Heroku is great for all sorts of websites, if money doesn’t matter. Otherwise, invest the extra time for a self-made deployment (leveraging existing tools like Capistrano of course), safe the money and get a better performance. Scaling EC2 is not as easy as moving a slider like it is for Heroku, but advanced dev ops/developers should have no problem adding a few servers to their load balancer in a reasonable amount of time.

Also consider using Heroku if you have a small app that probably won’t become huge in the far future to leverage the free hosting.

Tip: Blitz.io offers free rushing tests with a concurrency of up to 250 for Heroku apps (which isn’t free if you create a normal account there). But the tests aren’t restricted to your actual Heroku app. So you can create a free Heroku app, add the free Blitz.io addon and benchmark other websites as well (as long as they’re actually your websites of course).

Since Shopify doesn’t give you as much flexibility as Magento or other non-hosted systems do, I had to try around a bit to come up with some working code. It contains several things that Liquid provides, so it might be a good starting point for other problems as well. Here’s what I came up with in a compressed and simplified version:

Short answer

Code:

{% assign chars = '' %}
{% for vendor in shop.vendors %}
    {% capture first_char %}{{ vendor | truncate: 1, '' }}{% endcapture %}

    {% if forloop.first %}
        <div>
            <ul id="vendorlist">
    {% endif %}

    {% unless chars contains first_char %}
        {% unless forloop.first %}
               </ul>
            </div>
        {% endunless %}

        <div class="collectionitem one-third column vendor-container">
            <h2>{{ first_char }}</h2>
               <ul>

        {% capture temp %}{{ chars }}{{ first_char }}{% endcapture %}
        {% assign chars = temp %}
    {% endunless %}

    <li>{{ vendor | link_to_vendor }}</li>
{% endfor %}

Result:

Long version

There are quite a few things going on in here, so let’s check them out. In the first line the chars variable is preset which holds the used characters as a string, nothing fancy here. On the second line the variable shop.vendors is used to access an array of vendors. This was introduced lately. Not long ago you had to create this list on your own, which was quite a pain.

Next we capture the first char of the current vendor’s name, which is done using a small hack: using truncate to cut the word after the first char. Important: Make sure to use the second parameter as well, otherwise you’ll end up with three dots at the end, since that’s the standard setting for truncate.

forloop.first is used to determine if the current item is the very first vendor, which requires some additional markup. Hint: forloop.first, forloop.last and forloop.length only work within a loop.

If the chars variable doesn’t contain the current vendor’s first char yet, a new column is used for displaying the character in a headline. Then the char is added to the list of used chars to look them up during the next run. Note that the character is appended to the existing variable using a temporary variable.

Finally the vendor’s list item tag is displayed.

Even though the above code might look a bit strange if you’re used to developing the same stuff with actual programming languages, it’s still quite readable and understandable. Not bad for a hosted solution.

One way to do this is Trello. Trello is mostly a project management tool, which I use in a number of client projects. But since it’s so easy to set up a new board with an individual layout, it can be used for all sorts of things. Tracking goals is one of them. Here’s a standard layout I use to define my goals and keep track of my progress:

If my mind comes up with a new goal, I enter it in the very left column for the current year. If it’s a really long term goal, I might add another column for the upcoming year to the left. Once I accomplished something, I move it to the current month’s column. That way I have the “good feeling” of moving a card to done plus the progress is clearly visible, even for the last few months.

I use the same process for project management and other things like blogging. My blogging setup looks like this:

Again, new ideas go into the Ideas column. Once I have the time and the muse to write a blog post, I grab one of the cards and move it into Draft. The card stays there until I’m okay with the post and actually published it. Then it’s time to move the card into the current month’s column. Same rules apply here. With one quick look I can see how many posts I wrote during the last few months and if I might want to write another one (no pressure here, but I do have a growing list of cards in the Ideas column).

After trying a lot of different bug tracking/project management/todo list applications, Trello finally convinced me because of it’s Kanban-Style layout bundled with the easiness of creating boards and cards. I tried Asana for quite some time as well, but missed the possibility to see current progress and past progress that clearly. Bonus tip: Trello cards support Markdown which I use to write my blog posts as well. So cards are actually a nice way to get an initial draft out of your head very quickly.

To wrap this up, here’s another small hint: Use specific, if possible, timed goals. Don’t create a card that says “Lose weight” without a due date. Chances are you won’t met it. Try something like “Get down to X kg” with a due date that is not too far in the future but still possible (rather sooner than later). If you need two days more than the due date says, screw it, you managed it anyway! Giving yourself too much time is just counter productive (Parkinson’s law).

1
2
3
4
5
6

# Makefile

ENV ?= staging

deploy:
    my_deploy_script $(ENV)

So the deployment can be done like this:

1
2

$ make deploy # Deploys to staging since it's the default value
$ ENV=production make deploy # Deploys to production

This is useful in a variety of cases, like tests, generating docs and so on. Maybe you can find a use case for it in your workflow. It’s not a big deal, but can be nifty quite often.

Meetings are usually the worst thing you can do with your time! And I don’t mean 3 developers sitting around one screen to debug something. I mean those kinds of meetings which are scheduled by project managers and CEOs.

Employees getting pissed and sitting around a table for x hours doesn’t help anyone. The only definitive result is a headache. Meetings can be productive and useful but almost every time there are too many people invited, there’s no clear agenda (or there is and nobody cares), no clear time frame and so on. Watch Jason Fried’s talk on TED and you’ll know what I mean. He’s completely right. But especially project managers and CEOs either don’t know they’re wasting time and money or they don’t care because they think the meeting is “important”. Usually it’s not.

I know, a bunch of people already talked and wrote about this topic, but the thing is: nothing changed! Still too many meetings, too much bullshit, too much headache, too few features implemented.

Stupid, too long meetings have a huge impact on the company, especially on small ones. So if you’re working in one of them and you see this pattern, try to break it. Talk to your boss/project manager and try to solve the problem. Seriously. If they keep setting up meetings with 10 people for 8 hours to discuss something that actually takes 10 minutes for two of them and the remaining time is filled with unnecessary crap - leave. I mean it. I saw so many people being pissed sometimes the whole week, just because of this crap. It’s just no worth it.

If you’re a meeting scheduler, please, please think twice the next time. If it’s really necessary, fine, everyone will notice and appreciate it. But if it’s another worthless meeting and everyone knows about it beforehand, you’ll have a bunch of distracted people not giving a shit about what’s said in that meeting. Which means if you’re just skipping it, you have the same result (nothing changed in terms of the project), but with happier, more productive team members. Plus you probably saved your company a lot of time (e.g. 5 people having a meeting for 4 hours: 20 hours of productivity gone).

Thanks!

Initial setup

Let’s see how the initial widget.xml file (I had to integrate this feature into an existing extension which had a few widgets in it) was built:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<widgets>
  <Namespace_Module_Html type="module/widget_html" translate="name description" module="module">
    <name>Widget name</name>
    <description>Widget description</description>
    <parameters>
      <html translate="label">
        <visible>1</visible>
        <label>Input label</label>
        <description>Input description</description>
        <type>textarea</type>
      </html>
    </parameters>
  </Namespace_Module>
</widgets>

So far so good. As I discovered after a while, Magento loads classes from lib/Varien/Data/Form/Element based on the given type value. A quick look into the directory reveals a file called Editor.php. Job done!

1
2
3

<!-- ... -->
<type>editor</type>
<!-- ... -->

No errors. Good. No WYSIWYG. Bad. What happened? Unless you set the appropriate configuration values, the tinyMCE specific parts aren’t loaded, so a plain old textarea is rendered:

1
2
3
4
5
6
7
8

<?php
if($this->isEnabled()) {
    $this->setType('wysiwyg');
    $this->setExtType('wysiwyg');
} else {
    $this->setType('textarea');
    $this->setExtType('textarea');
}

Okay. Fine. Let’s set the config value in the XML file and we’re good to go, right? Nope. Unfortunately Magento doesn’t bypass all values you set in the XML file, only a few specific ones. So not helping. After quite some digging and searching on the web I found out that Magento doesn’t support any ‘complex’ field types for widgets, but it accepts a block instead of a type string.

Since there’s no documentation which block to extend or which interface to implement I had to spent some quality time debugging the crap out of Magento until I came up with this class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<?php
class Namespace_Module_Block_Widget_Wysiwyg extends Mage_Adminhtml_Block_Widget_Form_Renderer_Fieldset_Element
{
    public function render(Varien_Data_Form_Element_Abstract $element)
    {
        $editor = new Varien_Data_Form_Element_Editor($element->getData());

        // Prevent foreach error
        $editor->getConfig()->setPlugins(array());

        $editor->setId($element->getId());
        $editor->setForm($element->getForm());
        $editor->setWysiwyg(true);
        $editor->setForceLoad(true);

        return parent::render($editor);
    }
}

To actually load this block, change the type node in your xml to

1

<type>module/widget_htmleditor</type>

This should render your widget with a tinyMCE editor instance right there. Best case it looks something like this:

Bugfixing

As you already guessed as a long time Magento developer, this isn’t bug free. Main issue was the fact that Magento is using the contents of a textarea in the actual CMS page textarea to ‘render’ the widget, like this:

{{widget type="module/widget_html" text="Entered textarea content" template="module/htmlwidget.phtml" unique_id="someid"}}

The reason for this is that Magento’s using those parameters to reopen the widget popup with a pre populated form when clicking the widget image twice. Which is not a problem until you have html in your text parameter. Since it’s displayed inline, the widget image is broken and you see the HTML you entered. Plus the double click doesn’t work anymore of course.

My solution was to override Mage_Widget_Adminhtml_WidgetController::buildWidgetAction to save the contents as base64 and decode it when needed. Here’s the whole solution, feel free to save yourself a day of work and use it ;)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<?php
require_once 'Mage/Widget/controllers/Adminhtml/WidgetController.php';

class Namespace_Module_Adminhtml_WidgetController extends Mage_Widget_Adminhtml_WidgetController
{
    public function buildWidgetAction()
    {
        $type = $this->getRequest()->getPost('widget_type');
        $params = $this->getRequest()->getPost('parameters', array());

        if ('module/widget_html' == $type) {
            $params['text'] = base64_encode($params['text']);
        }

        $asIs = $this->getRequest()->getPost('as_is');
        $html = Mage::getSingleton('widget/widget')->getWidgetDeclaration($type, $params, $asIs);
        $this->getResponse()->setBody($html);
    }
}

1
2
3
4
5
6
7
8
9
10
11
12

<?php
/*
 * This is the widgets block, so "Widget_Html" maps to this line in widget.xml:
 * <Namespace_Module_Html type="module/widget_html" translate="name description" module="module">
 */
class Namespace_Module_Block_Widget_Html extends Mage_Core_Block_Template
{
    public function getText()
    {
        return base64_decode(parent::getText());
    }
}

And the updated widget block

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<?php
class Namespace_Module_Block_Widget_Wysiwyg extends Mage_Adminhtml_Block_Widget_Form_Renderer_Fieldset_Element
{
    public function render(Varien_Data_Form_Element_Abstract $element)
    {
        $editor = new Varien_Data_Form_Element_Editor($element->getData());

        // Prevent foreach error
        $editor->getConfig()->setPlugins(array());

        $editor->setId($element->getId());
        $editor->setForm($element->getForm());
        $editor->setValue(base64_decode($editor->getValue()));

        return parent::render($editor);
    }
}

But…

This only works for plain HTML. If you’re planning to enter CSS in your editor you’ll quickly notice that tineMCE is stripping it out, though it wouldn’t break anything because of the base64 encode. So you either switch back to use a plain textarea and only add the base64 part or you find a way to override the editors configuration to let him know to keep styles. Since I didn’t need it, I stopped digging deeper, especially because I already spent too much time on the lines above. I hope it helps somebody.

Take 30 minutes of Facebook from Monday to Friday. That’s 2,5 hours a week or 10 hours a month. 10 hours. More than a whole work day one could spent on Open Source, own projects, family time, learning a language, teaching something, working out and a thousand other things that actually have a value. The value of checking your Facebook timeline 5 times a day: Right…

Here’s the thing: People just don’t value their time and waste it, even though it’s the only thing we can’t buy, build, steal or get otherwise. And yet they pretend that they don’t have “enough time”. Ever “relaxed” the whole weekend even though you had a few things to take care of and felt really bad Sunday evening? Same thing.

You see I hear people telling me they want to learn X or build Y or finish Z. The most efficient way of actually make it happen is: make it happen. I know, easier said than done, but that’s how it is. No fancy project management tool or todo list app will help you, if you can’t get your ass off the couch. Those apps and tools can improve your productivity, but for that you actually have to be productive in the first place.

If you have a task that’s pretty small (< 1h), just do it right away. Don’t procrastinate. Just don’t. If you’re planning a big project (multiple weeks or months) and you’re one of those people who struggle to start things, here’s another advice: make it public. Tell everyone about your project and your deadline. In 9 out of 10 cases, this will boost your will and your productivity. For instance: After my publisher announced my first book, I spent twice as much time writing it than before because I felt the preasure and it was a good type of preasure. Try it. Make it happen.

If you think about starting a business in Germany, here are the steps for an UG (GmbH is basically the same) to get it done:

1. Ask the IHK if your desired name is actually allowed and free (email is fine)
2. Make an appointment with the notary and bring the completed form he (hopefully) gave you beforehand
3. Make an appointment with your bank of choice (I chose Deutsche Bank since they’re pretty cheap), if possible directly after the notary appointment. Make sure to bring the stuff the notary gave you
4. Go to the appointments
5. Transfer the capital to your newly created bank account, once you got the account number
6. Pay the notary from your private account and tell him you transfered the capital
7. The notary will do his job now and send everything to the right places
8. Wait for a letter from the district court about your entry
9. Go to the Office of Trade and register your company there (bring the notary stuff, the letter and your passport)
10. Take the stuff they gave you and the rest and make an another appointment with the bank to change the account holder
11. Wait for a letter from the tax office, fill out the form and send it back
12. Wait for the response so you get your tax number
13. Done, make some money!

Appendix: Don’t forget to get a health insurance! This can be done any time during the above process, the earlier the better.

Explanation

Now let’s explain this in more detail. Steps 1-8 should be pretty straight forward. For step 1 find an email address on the IHK’s website and your mail will find the right employee. Of course you should stop the process with step 1 if they tell you the name isn’t available for whatever reason. Step 9 is pretty easy as well, since the only thing you have to do is to wait for the letter, but besides the official letter you’ll receive quite a few invoices from different companies who are charging you for the court entry. Do not pay them. There’s only one official invoice and it’s from the actual court and usualy way cheaper than the others (I’ll talk about the costs later).

Step 10 might seem strange to you because of the phrase “change the account holder”. What that actually means is this: When the notary registered your company (in this case the UG), he actually requested a registration. Until that is done (step 8) your company isn’t a UG, it has the appendix “i.G.” which stand for “in Gründung” (basically “in the process of founding”). So your bank account’s holder isn’t AwesomeCo UG, it’s actually AwesomeCo i.G. You might think that’s not a big deal, but be aware: Until your company is actually a UG or GmbH, you’re liable as a private person! So even though you could use the company as of step 8 for business, you shouldn’t!

Steps 11 to 13 should be straight forward again. The tax office form isn’t that hard, if you really need to, get yourself a tax consultant. Btw: I did the whole founding process without a tax consultant and I still don’t have one.

Costs

This was pretty hard to figure out beforehand since I found wide ranges of numbers on the web. So here’s what I paid, notice that the costs differ slightly from state to state in Germany:

• Notary: 104,13 €
• Court: 151,00 €
• Office of Trade: 26,00 €

So overall I spent around 280 € for founding my company.

Time

This is what actually pissed me off. If you follow Hackernews or tweets/feeds in the business sector, it seems like it takes almost no time to start a business in the US. Well, not in Germany. The above mentioned process took me almost 3 months to actually get everything together (full disclosure: Actually a bit more than 2 months to file invoices in Germany only and almost 3 months to be able to file invoices outside Germany as well). And I’m talking about the UG here, which can be compared to the “Inc.” in the US.

Capital

As mentioned above, UG is basically like the Germany version of “Inc.”, so you could start your business with 1 €. Since that doesn’t make sense (you can’t even pay the notary), you should invest at least 1.000 €, otherwise you have to file insolvency right away. If you’re willing to invest 12.500 € (with a liability of 25.000 €), you can start a GmbH. Same process but the costs for the notary are way higher.

The name

Well well… Let’s say you want to call your company Awesomly and the IHK is fine with that. If you actually want to use your company’s name somewhere (imprint, mail footer, etc.) it’s not just “Awesomly”. This is against the law. In Germany you have to use the full name, or at least an official shortcut. Now if you’re from the US and used to “Awesomly Inc.”, here you go, this is the shortest possible version:

Awesomly UG (haftungsbeschränkt)

Neat huh? If you’re willing to invest the mentioned 12.500 €, you can use “Awesomly GmbH” but the downside of that is that you have a liability of 25.000 €. So if something bad happens, you have to pay the remaining 12.500 € as well. Not so for the UG. If you have 2.000 € in your account, that’s it. Furthermore you actually have your money sitting on the company’s account. Since my company is 80% agency and 20% own projects it doesn’t make sense to have a lot of money on the account sitting there, almost unreachable and earning between 0 and 0.x% interest. I rather have my money on my private account, freely available, with a lot more interest. That’s the main reason I chose UG over GmbH.

Wrap up

It’s actually not that hard to start a business in Germany but you need to know how. I spent quite some time before I started the whole process to get everything straight. And since the information on the web was distributed across a lot of websites, it wasn’t really easy to get the whole picture. Hopefully I made that with this post.

If you’re planning to start a business or already in the process of doing so, I wish you all the best, good luck and happy customers!

If you have questions, suggestions or want to share your experience, get in touch on Twitter.

Do not, I repeat, do not introduce core hacks

This might seem like a clear matter, but in fact there are still too many core hacks out there (usually in whole shop projects, not extensions). Even though include hacks are not the same as core hacks, I kinda hate them both. Magento gives you a huge interface to override and extend classes, methods, layouts and templates. Use it.

Consistent style

Again, a completely obvious point, right? Yet, I saw extensions from well known Magento agencies which looked like 5 people who never spoke to each other and don’t like each other worked on it. Of course, sometimes you have to add a quick fix and you might not double check the style. But having camelCase and snake_case methods in the same class just doesn’t look good. Especially since Magento uses the Zend standard, which you should do too. Also commented methods, sometimes more than 100 lines long are a no go. Speaking of 100 lines of code. Try to shrink your methods down to 50 lines tops, rather less than 25. I know, this is pretty hard in PHP and Magento sometimes, but try.

Do not comment out child block

One thing I found pretty annoying when taking over projects with template overrides was stuff like this:

1

<?php // echo $this->getChildHtml('child_name'); ?>

This is a really bad idea. If you don’t want to have certain blocks in a template, remove the code from the template and the layout xml file. Everything else is just confusing and time wasting.

Document your code and/or offer a PDF documentation

I’m not a big fan of doc blocks per se, since most people just add them because they have to but then fill them with barely useful information. Yet, feel free to add them to your methods to explain what they’re doing. But the actual power lies in inline comments. Especially if conditions tend to be introduced without further explanation. As a extension user I then try to figure out why the heck the developer added this if and how I should handle it. It’s just one line and makes your code more maintainable for both yourself and your customers.

Sometimes extensions become too big to just rely on code documentation. I’m not talking about customer documentation here (which should always be available either on your homepage or via PDF) - I’m talking about a documentation on how to extend your extension. To give you a concrete example: A few days ago I was working on a shop and had to extend a rather huge extension. After digging into the code for hours, me and my colleague still had no clue at all how this thing worked, where to start and what to do. This was actually the first time in my developer life I had such a moment. Then I went out to check for some information on Google. Nothing. You got the point…

Good architecture and API

If you’re building one of the bigger extensions, think about the extension’s structure and API. Unfortunately most big extensions lack this. It’s hard to determine what’s going on because of the weird structure and it’s hard (read: complicated) to actually interfere with the extension because method calls accept/require strange parameters or methods consist of 300 lines and do 10 things at once.

Test your code

This one is pretty hard since unit testing in Magento is a pain. But it’s still better the go through that pain and have a well tested code base than releasing untested extensions (maybe even paid ones?). Testing is not something fancy you can use if you’re one of those early adaptors. No. It’s mandatory, improves stability and maintainability and also helps you with a few of the above mentions points like structure and API. The worse your API the harder it’ll be for you to test it.

Wrap up

I’m sure not everyone/every agency has the time/the customers to keep all those things in mind, even though they should. So at least pick one for your next project and try hard to make it happen. Seriously. Everyone will benefit from it, there a no losers!

Assume you write HTML code. If you enter a single whitespace what will your browser render? Right, a single whitespace. Now write a second whitespace, right behind the first one and reload. Aha! Still one. Even if you could write two exclamation marks and the browser would render two, the bottom line is the same: It doesn’t make a difference.

You got the point write? So stop writing two, three or even more exclamation marks in a row. Whoever will read your text will not tread it more serious just because you feel like you need to add more than one to express yourself. Actually sometimes it’s the opposite. In my experience nearly 50% of the people receiving orders from their bosses via text react rather pissed when the order comes with multiple exclamation marks. By the way: I’m one of them ;)

PS: Same goes for question marks and three dots in every sentence.

Direkt auf natives Collection-Objekt zugreifen

Möchte man z.B. ein Dokument via Mongoose in die MongoDB speichern, aber sämtliche Hooks und Validierungen umgehen, kann man direkt auf die Collection zufreifen. Dies ist logischerweise bedeutend schneller als der “offizielle” Weg und somit interessant für Bulk-Inserts.

1

Entry.collection.insert({ title: 'Foo' });

Das Gleiche gilt natürlich auch, wenn man z.B. eine komplette Collection löschen will (anstatt sie zu leeren):

1

Entry.collection.drop();

Eine Liste von Spalten/Pfaden erhalten

Es kommt des öfteren vor, dass man durch die möglichen Pfade gehen muss um z.B. auf Vorhandensein oder ähnliches zu prüfen. Es gibt viele mögliche und unmögliche Anwendungsbeispiele. Um dies zu erreichen kann man sich eine Liste der Pfade aus dem Schema des Models holen.

1

Entry.schema.paths;

Einzelne Pfade mit definierter Validierung validieren

Es kann vorkommen, dass man nur einen einzigen Pfad eines Model validieren will, da der User z.B. nur diesen einen Pfad im UI eingeben kann und man nicht das komplette Model befüllen will. Hierfür wäre es natürlich schön, wenn man ein Model mit dem einzelnen Parameter instanziiert und nur diesen validiert (andernfalls könnte z.B. eine andere Validierung fehlschlagen, da Parameter fehlen und der eigentlich interessante Parameter würde garnicht erst getestet werden). Glücklicherweise kann dies wie folgt umgesetzt werden, sogar ohne ein Model effektiv zu instanziieren.

1
2
3
4
5
6
7
8
9

Entry.schema.paths.title.doValidate('zu kurz', function(err) {
  console.log(err);
});

// Oder

Entry.schema.path('title').doValidate('zu kurz', function(err) {
  console.log(err);
});

Änderungen am aktuellen Objekt einsehen

Manchmal möchte man z.B. innerhalb eines Pre-Save-Hooks bestimmte Funktionen ausführen, falls bestimmte Pfade verändert wurden. Vor allem beim Ändern von Sub-Dokumenten ein interessanter Fall. Hierfür benötigt man die Liste von geänderten Pfaden, auf welche man über folgende Funktion zugreifen kann.

1
2
3
4
5

entry._dirty();

// Oder um das Delta zu sehen

entry._delta();

‘createdAt’ und ‘updatedAt’ als Plugin

In der Rails-Welt ist es gang und gebe, dass jedes Model einen created_at und einen updated_at Timestamp hat. Für Mongoose gibt es bereits einige Module die Plugins mit entsprechenden Funktionalitäten anbieten, allerdings kann man dies auch schnell selbst implementieren.

In der Plugin-Datei, z.B. timestampable.js:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

module.exports = function(schema) {
  // createdAt
  schema.add({ createdAt : {
    type: Date,
    default: Date.now,
    required: true
  }});

  // updatedAt
  schema.add({ updatedAt : {
    type: Date
  }});

  // updateAt aktualisieren falls Dokument nicht neu ist
  schema.pre('save', function(next) {
    if (!this.isNew) {
      this.updatedAt = new Date;
    }

    next()
  });
}

Im jeweiligen Model:

1
2
3
4
5
6
7
8
9
10
11

var timestampable = require('./pfad/zum/plugin/timestampable')
  , mongoose      = require('mongoose');

var Schema = mongoose.Schema({
/**
 * Schema Definition...
 */
});

// Plugin einbinden
Schema.plugin(timestampable);

Problem: Mongoose-Skript endet nicht

Sollte man Mongoose in einem separaten Skript einsetzen, zum Beispiel in einer Migration, kann es passieren das Mongoose seine Arbeit getan hat, man allerdings dennoch keinen Prompt auf der Kommandozeile erhält. Dies liegt daran, dass Mongoose die Verbindung zur MongoDB offen hält und das Skript somit nicht endet. Einfachster Weg ist hier natürlich die Verbindung zu trennen.

1
2
3
4

mongoose.disconnect();

// Ggf. noch:
process.exit();

Debugging-Ausgabe

Wer gerne jede Query auf der Kommandozeile einsehen will, der kann innerhalb von Mongoose die Debugging-Ausgabe aktivieren, welche für alle Models und Queries global verwendet wird (solange die gleiche Mongoose-Instanz verwendet wird natürlich). Dies trifft übrigens auch zu, wenn man den oben genannten Shortcut über Model.collection nutzt.

1

mongoose.set('debug', true);

Abschluss

Wer weitere Vorschläge für die Liste hat, möchte diese bitte in den Kommentaren hinterlassen. Das Gleiche gilt für Fragen, die in diesem Post nicht beantwortet wurden. Vielleicht hatte ich schon mit dem einen oder anderen Problem zu tun und habe es bisher nur nicht in die Liste aufgenommen. :)

Zu allererst muss ich sagen, dass ich seit knapp 8 Jahren PHP entwickle, seit 5 Jahren hauptberuflich. Letztes Jahr habe ich zudem das Zend Certified Engineer-Zertifikat erhalten. Node verfolge ich seit ungefähr einem Jahr, verstärkt eingesetzt wird es von mir seit einigen Monaten. Kommen wir zu den groben Eckpunkten: Sprache, Dependencies, Community, Frameworks und Module, Testing, Performance, Einsatzzwecke und persönliches Empfinden.

Spache

Node.js selbst ist keine Sprache, sondern ein serverseitiges Framework, das Javascript ausführt. Daher muss hier eher Javascript mit PHP verglichen werden. Hierbei gibt es meines Erachtens nicht wirklich viele Unterschiede. Sicher ist das OOP-Verhalten nicht das gleiche und sicher hat jede Sprache ihre Vor- und Nachteile, dennoch nehmen sich beide in meinen Augen nicht viel. Beide sind extrem verbreitet und der größte Teil der Entwickler kann mindestens eine von beiden (mehr oder weniger gut). Vor diesem Gesichtspunkt ein Unentschieden.

Dependencies

Hier punktet Node ganz klar mit npm. Sicher gibt es für PHP PEAR, doch Hand aufs Herz, niemand mag es, es ist buggy, langsam und grauenvoll zu bedienen. Leider wurde hier von der PHP-Community nie nachgebessert, denn das Problem ist nicht das npm soo gut ist - nein, PEAR ist einfach so schlecht. Das Auflösen von Abhängigkeiten ist in anderen (Web-)Sprachen wie Ruby und Python genauso einfach und simpel. Node:1, PHP: 0.

Community

Das ist ein ganz heißes Eisen. Hier muss man fast mit zweierlei Maß messen. PHP hat mit Abstand die größere Community, allein schon durch die enorme Verbreitung, vor allem in Europa. Gerade Deutschland ist PHP-Land und wird es auch noch lange bleiben, da Innovationen aus den USA und Asien immer erst sehr spät oder gar nicht bei uns einen Fuß in die Tür bekommen (siehe die immer noch geringe Verbreitung von Django und Rails). Allerdings ist in Punkto Quantität die Node-Community wohl jetzt schon eine Liga über PHP. Es werden extrem viele Module und Tools veröffentlicht, ein Großteil sowohl OpenSource, als auch mit extrem hoher Code-Qualität. Das Tempo der Node-Community ist astronomisch, hier ist nur noch das Rails-Ökosystem vergleichbar, das ähnlich agil arbeitet. Unterm Strich muss die schiere Größe der PHP-Community allerdings auch einberechnet werden, daher erneut ein Unentschieden.

Frameworks und Module

Hier trennt sich die Spreu vom Weizen. PHP geht hierbei in meinen Augen einen schlechten Weg, indem Frameworks wie Symfony2 (hat mich nicht umgehauen, aber ok) und Flow3 (ohne Worte) veröffentlicht und angepriesen werden. Nachdem ich mit vielen davon arbeiten konnte/musste, scheint mir Zend Framework Version 1 nach wie vor das beste PHP-Framework zu sein. Leider gibt es auf PHP-Seite keine Innovation, sondern nur Revolution bzw. gefühlten Rückschritt (Stichwort Annotations in PHP, imho inakzeptabel, sowie z.B. gängige Template-Engines). Node hat hier den Vorteil, dass einfach vor einigen Monaten nur sehr wenig existierte und die Entwickler sich ihre Sachen neu bauen bzw. portieren mussten. Und wenn dies der Fall ist, werden natürlich die besten Sachen aus allen Sprachen/Frameworks einbezogen. Zum Beispiel:

• Template-Engine jade: Port von Haml inklusive einigen Verbesserungen
• Routing-Framework express: Port von Sinatra inklusive Verbesserungen und Erweiterungen
• CSS-Generator stylus: Innovation mit Einflüssen aus less und SASS
• Test-Framework mocha: Rspec ähnliches Framework
• CSS3-Extensions mit nib: Vergleichbar mit compass
• usw.

Beim aktuellen Stand der Dinge ein klares 2:0.

Testing

Das leidige Thema mit den Unit-Tests in PHP. Nachdem man in Node, Ruby oder Python getestet hat und zurück zu PHP kommt, denkt man der Rechner komprimiert im Hintergrund 10 Filme auf insgesamt 10MB. Natürlich ist es möglich mit PHP-Applikationen komplett zu testen und auch Test-driven zu entwickeln, allerdings ist die Geschwindigkeit nicht gerade berauschend und vor allem die Auswahl an möglichen Tools ist so klein, dass es einfach nur demotiviert. Hier fehlen ganz klar Pendants zu Rspec, Cucumber, Mocha, Vows, Test::Unit und wie sie alle heißen. 3:0

Performance

Auch das ist ein zweischneidiges Schwert, da auch PHP in Kombination mit z.B. Memcached durchaus schnell sein kann - und wenn ohnehin alles aus dem Cache kommt, kann auch Node mit seinem asynchronen Verhalten (außer beim Unit-Testing) nicht punkten. Technisch gesehen ist Node sicher schneller, schon allein durch den asynchronen Aufbau, aber da bei heutigen Webseiten ohnehin 90%+ aus dem Cache kommen sollten: Unentschieden.

Einsatzzwecke

Nun, in Punkto Einsatzwecke ist PHP Node wohl einige Schritte voraus. Durch die extrem hohe Akzeptanz in Europa bietet jeder noch so kleine Shared-Hoster mindestens irgendeine PHP5-Version, zusammen mit einem Apache an. Somit kann man für sehr wenig Geld seine eigene Applikation hosten und warten. Für den Einsatz von Node.js bedarf es in den meisten Fällen eines Servers, oder man nutzt die Angebote entsprechender Cloud-Dienste (hervorzuheben ist hier Heroku, die es unglaublich einfach machen kostenlos und sexy zu deployen).

Weiterhin ist Node aber auch nicht für jede Applikation geeignet. Gerade CPU-intensive und IO-lastige Aufgaben nehmen Node den Wind aus den Segeln (sicher, das kann man vorbeugen, aber dennoch). Ich teile die Meinung von einigen Leuten nicht, die sagen “wenn man eine Content-Webseite erstellen will, muss es PHP sein, Realtime mit Node”. Das ist zu einfach formuliert und imho auch falsch. Ich sehe das eher so:

• Realtime/Asynchron: Node
• Anfänger im Bereich Development: Erst Node ansehen, dann PHP
• APIs: Node
• Sehr schnelle Entwicklung mit enger Deadline: Ruby oder Python
• Nur Shared Hoster: PHP
• Du findest Flow3 gut: PHP
• Du testet gerne und viel: Node, Ruby, Python, Java
• Du hast PHP-Erfahrung und schreibst eine MySQL-basierte App: PHP
• Du hast ein schlechtes Feeling bei einem der beiden: Das Andere

Am Ende ist PHP wohl einfacher und schneller einzusetzen. Da es auch bei so gut wie jedem Applikations-Typ eingesetzt werden kann, steht es 3:1.

Persönliches Empfinden

Wie gesagt habe ich relativ viel Erfahrung mit PHP und Node sammeln können und bin zu folgendem Ergebnis gekommen: Node liegt mir einfach bedeutend mehr (genau wie Ruby). Die Community ist unglaublich und die Entwicklung ist wirklich einfach und der Code platzsparend. Unit-Testing macht noch mal 50% mehr Spaß als bei Ruby (durch die Geschwindigkeit, sorry Rails…) und die zur Verfügung stehenden Frameworks/Module sind einfach gut. Außerdem gefällt mir der sehr kleine Stack:

1
2
3

$ git clone
$ npm install
$ node app.js

Und schon läuft die App. Da es sich um einen komplett persönlichen “Gefühlseindruck” handelt, vergebe ich in dieser Kategorie keinen Punkte.

Abschluss

Ich will mit diesem Artikel auf keinen Fall eine der beiden Optionen haten oder liken. Es geht nur um das was ich in letzter Zeit wahrgenommen und gesehen habe. PHP hat seine Vorteile und so auch Node, allerdings hat Node mit 3:1 immerhin in den von mir angesprochenen Kategorien gewonnen.

Jeder muss für sich selbst und von Projekt zu Projekt entscheiden, was das richtige ist. Mein Tipp: Bitte einfach beim nächsten Projekt genau recherchieren, was das Richtige ist und was am meisten Sinn macht - sowohl kurzfristig als auch langfristig. Sätze wie “Wir schreiben es mit PHP und Framework X, weil das unsere Kernkompetenz ist” sind schlichtweg Blödsinn. Entwickler müssen neues entdecken und sehen, um auch bei den bereits bekannten Sachen besser zu werden. Man erkennt zum Beispiel am PHP-Code eines guten Entwicklers, wenn er schon einmal mit Rails gearbeitet hat ;)

Also: Immer schön recherchieren und ruhig mal 1 Woche oder mehr zum testen der Tools und Sprachen Zeit nehmen. Das Lesen der Dokumentation alleine reicht nicht aus!

Kernstück und fast einzige nötige Konfiguration ist die Datei .travis.yml im Root-Ordner des jeweiligen Projektes. Diese könnte wie folgt aussehen:

1
2
3

language: node_js
node_js:
    - 0.6

Jaaaaa, mehr nicht :) Wie unschwer zu erkennen, handelt es sich dabei, wie oben bereits angesprochen, um ein Node.js-Projekt. language legt somit einfach die verwendete Sprache fest, node_js die zu testenden Versionen. Weitere Informationen zu den möglichen Optionen finden sich in der ausgezeichneten Dokumentation.

Im Falle von Node.js führt Travis automatisch das Kommando npm test aus. Damit NPM auch weiß, was dabei zu tun ist, bedarf es ein paar Zeilen in der entsprechenden package.json-Datei:

1
2
3

"scripts": {
    "test": "make test"
},

Das Kommando sollte natürlich auch vorhanden und ausführbar sein (ich verwende Makefiles in Verbindung mit dem Testing Framework Mocha). Danach muss man nur noch auf die Webseite von Travis gehen, sich via Github einloggen und das Repository aktivieren. Schon führt Travis bei jedem Push die Tests aus und verschickt im Fehlerfall E-Mails. Ein schickes Frontend gibt es dazu natürlich auch. Alles kostenlos, hosted und unkompliziert - sehr nett!

Package.json

Kernstück des Moduls ist die Daten package.json, die NPM über Name, Version und Abhängigkeiten informiert. Das folgende Beispiel enthält die notwendigen Mindestanforderungen plus das Testing-Framework Mocha als Dev-Dependency:

1
2
3
4
5
6
7
8
9
10
11

{
  "name": "testapp",
  "description": "Mein Testapp",
  "version": "0.0.1",
  "author": "Mario Behrendt <info@mario-behrendt.de>",
  "devDependencies": {
    "mocha": "*",
  },
  "main": "index",
  "engines": { "node":">= 0.5.0 < 0.7.0" }
}

Die ersten Einträge sind wohl selbserklärend. Mit main legt man den Einstiegspunkt des Moduls fest, in diesem Fall die Datei index.js. Unter engines können die kompatiblen Node.js-Versionen eingepflegt werden. NPM prüft diese bei der Installation und weißt den Nutzer bei Inkompatibilität mit einer entsprechenden Fehlermeldung darauf hin.

Publishing

Angenommen das Modul enthält an dieser Stelle auch schon verwendbaren Code und der Name ist noch nicht belegt, kann die Veröffentlichung direkt beginnen. Hierfür muss, falls nicht bereits vorhanden, ein NPM-Account erstellt werden:

1

$ npm adduser

Danach wechselt man in den Überordner des Moduls und führt das Publishing durch.

1

$ npm publish $ordername

That’s it! Nun sollte das Package auch schon in der NPM-Suche aufzufinden und installierbar sein:

1

$ npm install testapp

Wenn man später neue Versionen des Moduls hochladen will, muss lediglich die Version in der package.json angehoben, sowie der publish Task erneut ausgeführt werden - NPM kümmert sich um den Rest.

Insgesamt empfand ich das arbeiten mit NPM als Modulentwickler sehr angenehm und unglaublich schnell. Teilweise dachte ich es kam zu Problemen und Fehlern, doch NPM war einfach schon nach extrem kurzer Zeit fertig. Ein gelunger Ausgleich zu “Package-Managern” anderer Sprachen, die hier ungenannt bleiben möchten.

In meinem Beispiel soll es ein User-Model geben, dass über die boolesche Eigenschaft active ausdrückt, ob ein Nutzer-Account durch einen Admin freigegeben wurde oder nicht. Um alle nicht aktivierten Accounts schnell aufzulisten und somit den Workflow für die Suche nach “zu prüfenden Nutzern” zu verbessern, bietet sich ein Quick Filter an.

Um einen Quick Filter zu definieren bedarf es lediglich eines Named Scopes. ActiveAdmin liest diesen nach einer kleinen Anpassung direkt aus und zeigt ihn im Frontend als Filter an. Basierend auf meinem Beispiel könnte das User-Model wie folgt aussehen.

1
2
3

class User < ActiveRecord::Base
  scope :inactive, where(:active => false)
end

Um den Scope innerhalb von ActiveAdmin zu registrieren muss der anzuzeigende Titel und der Scope-Name im entsprechenden Admin-Model definiert werden.

1
2
3

ActiveAdmin.register User do
  scope "Inaktiv", :inactive
end

Das Ergebnis sieht im Frontend schließlich wie folgt aus:

Indem man default auf true setzt, kann ein Filter außerdem als Standard markiert werden. Somit wird beim Aufruf des Grids immer direkt nach dessen Kriterien aussortiert:

1
2
3

ActiveAdmin.register User do
  scope "Inaktiv", :inactive, :default => true
end

Wenn man via rake eine neue Admin-Resource erstellt, legt ActiveAdmin automatisch einen neuen Menü-Punkt, mit dem Namen der Entität als Label, an. Wenn man allerdings viele Entitäten/Models hat, wird dieses Menü recht schnell sehr breit und unübersichtlich. ActiveAdmin bietet hierfür die Möglichkeit an, Menüpunkte ineinander zu verschachteln - automatisch generierte Dropdowns inklusive. Und so geht’s:

Angenommen es gibt die beiden Models Interviews und Interview_Questions. Jedes Interview kann also beliebig viele Fragen zugewiesen bekommen. Da diese beiden Entitäten doch sehr stark voneinander abhängen, sollen sie einen gemeinsamen Menüpunkt bekommen.

1
2
3

ActiveAdmin.register Interview do
  menu :parent => "Interviews", :priority => 1
end

1
2
3

ActiveAdmin.register InterviewQuestion do
  menu :parent => "Interviews", :priority => 2
end

Auch ohne viel ActiveAdmin-Erfahrung lässt sich hier recht schnell ausmachen was geschieht. In beiden Fällen wird der Eintrag innerhalb des Elternpunktes Interviews hinterlegt, wobei die Priorität über die Reihenfolge innerhalb des Dropdowns entscheidet (1 == ganz oben). Und so sieht es dann im Frontend aus:

Neben priority und parent stehen außerdem noch zwei weitere Optionen für Menüeinträge bereit: label und if. Mit dem ersteren kann, wie nicht schwer zu erraten, der Anzeigestring im Menü angepasst werden. Wer also statt den englischen Namen des Models Interviews lieber Gespräche verwenden will, kann dies via label tun.

1
2
3

ActiveAdmin.register Interview do
  menu :label => "Gespräche"
end

Mit if kann ein Eintrag aufgrund einer Prüfung ein- oder ausgeblendet werden. Bestes Beispiel: Sollte der aktuelle Benutzer nicht berechtigt sein eine bestimmte Entität zu editieren, ist es auch nicht nötig ihm den entsprechenden Menüpunkt anzuzeigen.

1
2
3

ActiveAdmin.register Interview do
  menu :if => proc{ current_admin_user.can_edit_interviews? }
end

Zum Schluss noch ein kleiner Hinweis zum if. proc wird im Kontext eines Views ausgeführt - es ist somit also der Zugriff auf alle Variablen und Methoden möglich, die auch in einem “normalen” View zur Verfügung stehen würden.

Wer bereits mit Django entwickelt hat, für den sind schnell aufgesetzte, hochfunktionale und schicke Admininterfaces nichts neues. Doch auch in der Ruby-Welt gibt es das ein oder andere ernstzunehmende Gem, das ähnliche Features bereitstellt. Nebenbei bemerkt finde ich diese Trennung von den einzelnen Gems in Ruby besser gelöst als das Out-of-the-Box-Adminterface von Django. Auch wenn es schön ist, direkt nach der Einrichtung eines Projektes Zugriff auf diese Möglichkeiten zu haben, scheint mir die Auslagerung wesentlich sauberer und schicker.

Doch zurück zu den Kontrahenten. Aktuell scheinen zwei Gems um den Platz des besten Backends zu kämpfen: ActiveAdmin und RailsAdmin. Nachdem ich mir beide etwas näher angeschaut hatte, fiel meine Entscheidung auf ActiveAdmin. Es sieht nicht nur wesentlicher schicker aus - es ist auch noch super einfach zu bedienen. Auch komplexe Backends sind in wenigen Stunden erledigt. Folgend werde ich kurz auf die Installation sowie einige Beispiele eingehen.

Installation

Da ich ActiveAdmin innerhalb einer Rails-Applikation getestet habe, werde ich meine Beispiele auch auf diese beziehen. Da alle neueren Rails-Apps mit Bundler laufen sollten, gestaltig sich die Installation mehr als einfach.

1
2
3
4
5

gem 'activeadmin'

# Falls Rails >= 3.1 verwendet wird zusätzlich
gem 'sass-rails'
gem "meta_search", '>= 1.1.0.pre'

1
2

$ bundle install
$ rails g active_admin:install

Der Installer erstellt automatisch einen neuen Ordner app/admin und legt den entsprechenden Initializer an. Danach sollte die Datenbank mit den neuen Tabellen (unter anderem Admin-Nutzer) befüllt werden:

1

$ rake db:migrate

Wenn man nun den Server startet (rails s) und http://localhost:3000/admin aufruft, kann man sich mit den folgenden Zugangsdaten einloggen:

Username: admin@example.com
Password: password

Verwendung

Um nun die entsprechenden Admin-Models zu erstellen, bietet das Gem eigene Kommandos an - bestehende ActiveRecord-Models vorausgesetzt.

1
2
3

$ rails g active_admin:resource [Modelname]
# Beispiel
$ rails g active_admin:resource news

Das neue Model ist nun in app/adminzu finden. ActiveAdmin löst Relationen zwischen ActiveRecord-Entitäten automatisch selbst auf und konvertiert die jeweiligen Spaltentypen in sinnvolle HTML-Input-Felder. ID-Relationen werden somit zu Dropdown-Selects, Strings zu Input-Text-Feldern, Booleans zu Checkboxen und Texte zu Textareas.

Wenn man nun im Browser die Rails-App aufruft erhält man bereits ein funktionsfähiges Backend, samt Menü und einer Kommentarfunktion. In den nächsten Tagen werde ich weitere Artikel zur Konfiguration und Anpassung des Interfaces veröffentlichen. Eins sei schon vorn weg gesagt:

Sowohl das Grid als auch Detailseite, Formulare, Menüs und Dashboard lassen sich sehr einfach und flexibel anpassen. Scopes sind außerdem wunderbar als One-Klick-Filter einsetzbar.

1

$ mongo performancetest

1

> var i = 1; for (i = 0; i < 1000000; i++) { db.Example.save({ value: i }); }

Dieser Vorgang kann je nach Rechner einige Sekunden dauern. Danach kann man das Ergebnis mit einem Aufruf von count überprüfen.

1
2

> db.Example.count()
1000000

Um jetzt die zeitlichen Unterschiede zwischen einer Query ohne Index und einer mit zu ermitteln, bietet sich der Profiler an, welcher über folgende Methode gestartet werden kann.

1
2

> db.setProfilingLevel(2);
{ "was" : 0, "slowms" : 100, "ok" : 1 }

Zu beachten gilt hierbei, dass im Loglevel 2 alle Queries geloggt werden. Wer nur langsame Queries loggen möchte, kann dies mit dem Loglevel 1 und der Angabe einer Grenze bewerkstelligen.

1
2

> db.setProfilingLevel(1, 20);
{ "was" : 0, "slowms" : 100, "ok" : 1 }

Der obige Code weist den Profiler an nur Queries zu loggen, die länger als 20ms benötigt haben. Für meinen Test habe ich Level 2 genutzt, um wirklich alle Vorgänge einsehen zu können. Wenn man nun eine Query auf einen bestimmten Eintrag abfeuert:

1
2

> db.Example.find({ value: 555 })
{ "_id" : ObjectId("4f0c85b6f449de5f6c4c365c"), "value" : 555 }

Kann man im Profiler sehr schön die entsprechenden Einträge beobachten (Ausgabe verkürzt auf die relevanten Inhalte).

1
2

> db.system.profile.find({ "query.value" : 555 })
{ "query" : { "value" : 555 }, "nscanned" : 1000000, "nreturned" : 1, "millis" : 825 }

Wichtig ist neben der Query selbst, um diese zu identifizieren, der Wert nscanned, der angibt wie viele Datensätze gelesen werden mussten, um den gewünschten Eintrag zu finden. Unter nreturned versteht man die Anzahl von gefundenen Einträgen, ganz wie zum Beispiel die von MySQL bekannten Rows affected. Für meinen Test am wichtigsten ist allerdings der Wert millis, der - wie zu vermuten - die Dauer der Query in Millisekunden enthält (der Wert ist übrigens gerundet). 825 Millisekunden für einen einfachen Find ist schon grenzwertig, also auf zum Indizieren!

1

db.Example.ensureIndex({ value: 1 })

ensureIndex() prüft ob bereits ein Index auf der angegebenen Spalte liegt und erstellt diesen, falls keiner gefunden wurde. Die 1 bedeutet einfach nur soviel wie “Ja, diese Spalte sollte einen Index haben”. Dieser Vorgang kann je nach Größe der Collection ebenfalls einige Sekunden, bei sehr großen Datenmengen auch mehrere Stunden dauern.

Wenn man die oben genannte Query nun nochmals ausführt, zeigt sich einem ein vollkommen anderes Bild in den Profiler Logs:

1
2

> db.system.profile.find({ "query.value" : 555 })
{ "query" : { "value" : 555 }, "nscanned" : 1, "nreturned" : 1, "millis" : 0 }

Es wurde nur 1 Eintrag gescanned und die Query dauerte 0 Millisekunden. Die 0 ist natürlich ebenfalls gerundet, aber man sieht sehr schön wie viel ein Index in einer MongoDB ausmachen kann. Sicher handelt es sich bei meinem Beispiel nicht um Real World-Daten, doch unterm Strich kann man sagen:

Das Slow Query-Log sollte in regelmäßigen Abständen auf Bottlenecks geprüft werden. Durch gezieltes Indizieren und Testen der Auswirkungen kann viel Rechenzeit auf dem Server und somit Zeit für den User gespart werden. MongoDB reagiert mit extremen Performancesteigerungen durch wenige Änderungen an den Indizes - warum diese Möglichkeit also nicht komplett ausreizen?

Leider lies sich der MySQL-Server nach dem Upgrade nicht mehr hochfahren, was zur Folge hatte das mehr als zehn meiner Webseiten nicht mehr erreichbar waren:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

mysql-server-5.1 (5.1.49-3) wird eingerichtet ...
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!
invoke-rc.d: initscript mysql, action "start" failed.
dpkg: Fehler beim Bearbeiten von mysql-server-5.1 (--configure):
  Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von mysql-server:
  mysql-server hängt ab von mysql-server-5.1; aber:
  Paket mysql-server-5.1 ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten von mysql-server (--configure):
  Abhängigkeitsprobleme - verbleibt unkonfiguriert
Fehler traten auf beim Bearbeiten von:
  mysql-server-5.1
  mysql-server

Ein kurzer Blick in das syslog zeigte folgenden Eintrag:

1

Can’t open the mysql.plugin table. Please run mysql_upgrade to create it.

Diese fehlende Tabelle könnte theoretisch via mysql_upgrade angelegt werden - dazu müsste aber der MySQL-Server laufen. Die eigentliche Fehlerbehebung fand dann in der my.cnf statt, die offensichtlich veraltete Einträge enthielt.

1
2
3
4
5
6
7
8

# Backup anlegen
cp /etc/mysql/my.cnf /etc/mysql/my.cnf.backup

# Alte Version mit neuer ersetzen
cp /etc/mysql/my.cnf.dpkg-dist /etc/mysql/my.cnf

# MySQL-Server starten
/etc/init.d/mysql start

Danach sollte der Server wieder korrekt hochfahren und ordnungsgemäß funktionieren. Alternativ kann man natürlich auch ein diff machen - ich hatte aber keine wichtigen Anpassungen gemacht und war somit mit dem Überschreiben der Konfiguration zufrieden.

Ein schönes Beispiel dafür ist die Verwendung von git log. Die meisten werden es nur einsetzen um die letzten Commits und deren Committish abzufragen. Doch man kann es auch einsetzen um eine mehr oder weniger grafische Repräsentation der Historie zu erhalten. Für Freunde der Kommandozeile sicherlich ein interessantes Feature:

1

$ git log --pretty=oneline --abbrev-commit --graph --decorate

Das Ergebnis könnte dann wie folgt aussehen.