Hi

My name isBenjamin Erhart

I'm here tonight, because I love programming Perl.

But... I actually don't want to talk about Perl, which is, by the way, a great multi-purpose, multi-paradigmatic, community driven, often underestimated, mature programming language usable for all sorts of things and especially great for data centric web applications.

Instead I want to talk about things one level higher.

Theses for Better Mobile and Web Applications

Benjamin Erhartberhart@netzarchitekten.com

or:Various Rants about Programming Topics

BTW:If you want to learn about Perl, there's an Austrian Perl Workshop coming up occurring between November 2nd to 3rd at NCMs offices.

orjust ask me about a training!

whoami

Im self employed and partnered with friends at die.netzarchitekten.com

I'm a passionate software engineer in the fields of web and mobile with 10+ years experience and had worked my way up to Head of Development of leading SMEs.

I'm available for hire to build your next application, consult you and your team in the arts of proper version control and build management, how to program Perl and JavaScript or help with any security issues you might have application-wise!

1

Choose your tools depending on your problems, do not try to solve your problems with your favorite tools.

Why?

Seems obvious when standing in front of a toolbox.In IT, tools are often chosen because of the wrong reasons.

We already know them.

Sure, but: The average life of some technology on the internet is shorter than 10 years. So you better move on, if you don't want to fall behind!

We can't find people with knowledge in better ones.

So what? Good programmers will program good in any language. Just give them two weeks to have a look around, maybe kickstart them with a little training.

Your programmers are not so good, yet?Well, looking beyond one's own nose is the first step to become better. Let them explore new stuff!

It's too expensive to do it with these fancy new technologies.

The best fitting new technologies will save you development time, bug fixing time, customer care time and response time . Otherwise, they wouldn't be best fitting. I guess, that will make up for the extra costs...

The others use it, too!

Great! Then there's a perfect opportunity to get an advantage. The same tools surely won't buy you that.

2

Do not rewrite software from scratch, but evolve it constantly!

This lesson is actually 13 years old*, but worth repeating any time!

Everybody loves to start fresh, because:It's harder to read code, than to write it.

*) www.joelonsoftware.com

Evolve it constantly

Environment changes constantly, even if you don't recognize it for a while:Server hardware breaks, old OS versions don't run on new ones.Libraries in use change APIs in new versions. Documentation for old one vanishes.

If you stop development for year, chances are, your application will fall behind so much, you can't catch up anymore.

Enhance the old code

Put it in source control immediately if you haven't, yet!

Start versioning, if you haven't, yet!

Add a proper toolchain for continuous integration/deployment.

Add documentation.

Add unit tests.

Add automated interface tests, if the products value allows it.

Refactor, refactor, refactor.

One step at a time, to allow for a continuously working product.

Do not stick to old environments don't be afraid of building new parts with new technologies.

3

Avoid dependency hell for all it's worth!

Wealth through self-restraint

Avoid using other libraries in your own, which only make the language nicer.

Do not use libraries, which replicate behaviour of another library you already depend on, just because you think it's cooler.

If you can't get it into your (and your colleagues) build chain easily, don't use it!

Why?

Keep resource usage low.

Keep needed knowledge for new colleagues low.

Keep build times low.

Keep demands on IDEs and toolchain low. Not everybody loves your fancy editor.

Avoid unnecessary restraints and need to work around stuff which turn out to be not as a good an idea as thought in the first place.

Your going to pile up enough dependencies over time anyway!

4

API-ize your applications best as you can! restful

Testing

Complex MVC chains responding with HTML are hard to test. Web APIs returning data structures are way easier.

Server off-load

Move business logic to the client, render client-side.

Responsiveness

Viewer requests with shorter response times obviously feel less sluggish to the user.

Interoperability

Reuse your APIs to integrate into other websites or mobile applications.

Thanks for your patience!

Benjamin Erhartdie.netzarchitekten.com