Use HeidiSQL with your vagrant box

I already discussed how to use HeidiSQL with a remote server in a former post. I now switched to use a local Vagrant VM instead of a remote VM. Of course I still wanted to use my beloved HeidiSQL. And it is – again – very easy!

vagrant_setup_1

On the above page, you need to use the MySQL Username and Password.

vagrant_setup_2

On the “SSH tunnel” tab we have to use the Username and Password for the SSH connection. I use a Private Key instead of a password, so I leave the password empty and specify the Private key file instead.

My box is configured to use SSH port 2222 instead of the default port 22. This will most likely differ on other boxes, so it is worth to check this first if the connection is not possible.

That’s it :-)

Template Engines vs. PHTML

The Problem: Performance. Once again.

It was time to think again about the use of Template Engines (i.e. those like Smarty or Fluid who offer their own syntax) versus so called PHTML files (i.e. basically mixed HTML and PHP), as one of my colleagues currently works on a Typo3 Extbase extension with a very huge HTML output. Unfortunately the rendering process was extremely slow. In our case Fluid, the template engine that comes bundled with Extbase, was to blame.

Although using compiled templates, it took about 6 seconds to render. After clearing the cache it was way beyond 20 seconds until the templates were compiled again. What the heck. Where does this massive overhead come from?

Looking at the compiled templates, I was a bit shocked: one of it had almost 20.000 lines of PHP code, tons of closures and function calls! It was just a template, now it is a monster. 6 seconds rendering time is not acceptable at all. Surely the extension produced a big HTML code, using loads of loops, partials and view helpers, but we had to find a way to deal with it.

Two options where obvious at that moment:

  1. Do we really need to use Fluid?
  2. How about loading at least parts of the content, which is not immediately used, via AJAX?

I admit I’m biased. I never liked using any Template Engine in PHP. That’s why I had a closer look at option 1, while my colleague started working on option 2 meanwhile.

Considerations

Let’s think about the Pros and Cons of using template engines in PHP. Here is what we came out with:

Pros:

  • No PHP knowledge required to build templates: yeah, sure. This is a common argument. So it is ok for the Webdesigner to learn a new template engine, but too much to learn PHP basics. Plus, at least in our team there is nobody who doesn’t speak PHP.
  • Templates are cleaner, easier to read: this depends on the template engine of course, but considering Fluid I would agree on that. It is not very important for me, though.
  • No risk of PHP abuse in template: Yip, good point. I guess we’ve all had these “WTF!?!” moments when we looked at PHTML templates, finding functions with business logic in templates. This surely requires the coders to be disciplined, and/or Code Reviews.
  • Template Engines offer caching mechanisms: true. But without caching they wouldn’t even come close to the performance of PHTML files. There’s nothing to say against implementing your own caching when you use PHTML templates, though.

Cons:

  • Using a template engine produces overhead: you can’t ignore the fact that a templating engine per se is additional overhead. This is not necessarily bad, when the overhead is low, but when the content takes more than double the time to render it might not be the correct choice.
  • Templates can not be debugged properly: I’m used to develop using a PHP debugger a lot, especially when I have to deal with many variables and nested arrays. I can’t use that in templates. I can use it in PHTML files.
  • “Why did my change don’t come through? Ah, I forgot to clear the cache again!”: If this applies to you, as it does for me, then template engines can be a bit of a pain sometimes.
  • “I’m not slacking off, my code’s compiling”: Not only a smart reference to XKCD, but also a very annoying aspect: if you develop, you either turn off caching completely (slow!), or you have to clear the cache whenever needed (annoying – and slow!).

Ok, there are some points which speak for Template Engines, but are they really worth the overhead? This surely depends on personal preferences, but for me it was clear: No. It is not.

Conclusion: Go back

Great. We wanted to stick with Extbase, but we didn’t want to use Fluid all the time. So we need a PHTML template renderer for Extbase. It should at least cover the following requirements:

  • We want true MVC! View and Logic must be separated.
  • Extbase/Fluid must not be modified. Copy&Paste has to be avoided.
  • The PHTML renderer should be easy to integrate. Existing controller actions shouldn’t be rewritten at all.
  • The use of Fluid should still be possible.
  • Partials must be supported.
  • Fluid ViewHelpers should be supported, at least some sort of ViewHelpers must exist. Namespaces for ViewHelpers would be nice.

Of course there is a mayor drawback: all the Fluid templates which already existed need to be “backported” to PHTML. Oh well…

It should however show that the required goal was very easy to achieve. This will be shown in the next post.

What are your views on Template Engines? Maybe we missed the one argument to use them instead of PHTML?

Free! JavaScript! Literature!

Back in the days, one of my profs at the University always had some cool quotes at hand. One of his favourites was “There is no such thing as a free lunch”. While I basically agree (at least what food is concerned), you often find free gems in the internet, like a series of JavaScript related books:

https://github.com/getify/You-Dont-Know-JS

They are available for free on github, however the author also sells them as e-book or even printed versions. I’m not sure if I would pay $17 for a 98 pages e-book which I can read for free, though… that sounds a bit too expensive in my opinion.

Microsoft drops support for ancient IE versions (finally)

I was very pleased, happy, yes – almost euphoric when I read that Microsoft plans to drop support for older IE versions:

http://blogs.msdn.com/b/ie/archive/2014/08/07/stay-up-to-date-with-internet-explorer.aspx

While Windows Vista users will still get support for IE 9 (are there any Vista users out there anyway?), on Windows 7 only IE 11 will be supported. Aren’t that good news? After wasting billions of hours of webworkers precious livetime all over the world, Microsoft finally understood. A bit. I guess.

Debug shell scripts (well, kind of)

I have to look up this one frequently, because it is really helpful.

If you want to see what lines of a shell script are actually executed, place this line in your code:

set -x 

I usually do that after the funny thing called Shebang (#!/bin/bash – I can also never remember this one correctly), but surely you can place it right before the section where you expect the problem. If you have an idea where the problem might be, that is. If not, just start from the beginning.

Cool thing: the variables are replaced in the output, or as the man page puts it:

Print a trace of simple commands and their arguments after they are expanded and before they are executed