http://www.contentwithstyle.co.uk/feeds/rss/comments/31 Thu, 02 Sep 2010 14:52:30 -0400 Zend_Feed http://blogs.law.harvard.edu/tech/rss http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-113 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-113
A common technique here is to set up a class for each table that contains all queries.

This actually doesn’t sound like a very good idea to me, since I work with joint queries and subselects.

But then subselects are server-specific … Ohh dear …

I gotta think about this more thoroughly!]]>
A common technique here is to set up a class for each table that contains all queries.

This actually doesn’t sound like a very good idea to me, since I work with joint queries and subselects.

But then subselects are server-specific … Ohh dear …

I gotta think about this more thoroughly!]]> Thu, 02 Jun 2005 18:42:06 -0400 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-115 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-115
I would disagree with you, telling that the main benefit of separation of SQL from the page presentation is an easiness of finding the proper statement in a future. While it’s also true, the main aims of design patterns (and we are talking about MVC, Facade and some other patterns) are re-usability and isolation. You have uncovered the re-usability part a bit, but isolation plays a great role too (and it’s not about SQL only).

When you have a team you can define the classes, their roles and goals. After that spend a while to create stubs and spread the job across the team. Everybody will be building its own part: SQL expert – SQL, designers – presentation, the rest – logic programming. When finished, tested and re-joined together the parts form the application. Because of clear separation no one waits for others and knows clearly from A to Z what his own part should do. It’s just one of possible use-cases.

I have more to say, but I would better stop here as it’s going to be overloaded. :) Nice article! Keep up doing great job!]]>
I would disagree with you, telling that the main benefit of separation of SQL from the page presentation is an easiness of finding the proper statement in a future. While it’s also true, the main aims of design patterns (and we are talking about MVC, Facade and some other patterns) are re-usability and isolation. You have uncovered the re-usability part a bit, but isolation plays a great role too (and it’s not about SQL only).

When you have a team you can define the classes, their roles and goals. After that spend a while to create stubs and spread the job across the team. Everybody will be building its own part: SQL expert – SQL, designers – presentation, the rest – logic programming. When finished, tested and re-joined together the parts form the application. Because of clear separation no one waits for others and knows clearly from A to Z what his own part should do. It’s just one of possible use-cases.

I have more to say, but I would better stop here as it’s going to be overloaded. :) Nice article! Keep up doing great job!]]> Fri, 03 Jun 2005 08:01:22 -0400 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-116 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-116 I do agree with you. Thanks for pointing out a nice example for isolation. I know it’s not only about sql, and I think you summed it up very good.

I guess it slipped my mind, as I wanted to write this up for smaller projects, which hardly ever have more than 2 people developing it. But you’re right nevertheless. Feel free to add more, or drop me a line]]> I do agree with you. Thanks for pointing out a nice example for isolation. I know it’s not only about sql, and I think you summed it up very good.

I guess it slipped my mind, as I wanted to write this up for smaller projects, which hardly ever have more than 2 people developing it. But you’re right nevertheless. Feel free to add more, or drop me a line]]> Fri, 03 Jun 2005 11:43:37 -0400 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-117 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-117 Fri, 03 Jun 2005 13:28:34 -0400 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-118 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-118
The other good thing is that you always can start from writing tests for your future modules to set in stone what EXACTLY they should do (it’s called TDD – Test-Driven Development). You write scenario after scenario (generally using PHPUnit or other XYZUnit, depending on technology you are using). These scenarios should reflect the real-life problems the module is intended to solve. In example with Persistence Layer, it could be “Reading list of posts”, “Adding post”, “Adding Comment”... you got the idea. While writing the tests you add methods to your classes which help to solve your problems, group them, rename them, recognizing patterns and following them (over and over again). By the end of this process you will have the stub for your module, which is having all methods and clearly designed to solve your TODAY’S problems (nothing more, nothing less). After that you just spend some time to put in the implementation and pass all the scenarios you have set in tests. It’s all about modularity, layering and isolation.

As for me, I always try to work “from the tests” because if not, then I’m always thinking about the module from inside and doing too much assumptions, adding flexibility which is not likely to be necessary and etc. It all takes time.

Save your time, do it right. :) Some good reading on the subject could be anything about TDD, general articles by Martin Fowler (“Is Design Dead?”, for example) and of course the design patterns material. They aren’t the goal and you shouldn’t aim on using them all the time; they just help you to concentrate on real tasks instead of re-inventing the wheel.

Hope that it’s interesting and even inspiring to someone. :)]]>
The other good thing is that you always can start from writing tests for your future modules to set in stone what EXACTLY they should do (it’s called TDD – Test-Driven Development). You write scenario after scenario (generally using PHPUnit or other XYZUnit, depending on technology you are using). These scenarios should reflect the real-life problems the module is intended to solve. In example with Persistence Layer, it could be “Reading list of posts”, “Adding post”, “Adding Comment”... you got the idea. While writing the tests you add methods to your classes which help to solve your problems, group them, rename them, recognizing patterns and following them (over and over again). By the end of this process you will have the stub for your module, which is having all methods and clearly designed to solve your TODAY’S problems (nothing more, nothing less). After that you just spend some time to put in the implementation and pass all the scenarios you have set in tests. It’s all about modularity, layering and isolation.

As for me, I always try to work “from the tests” because if not, then I’m always thinking about the module from inside and doing too much assumptions, adding flexibility which is not likely to be necessary and etc. It all takes time.

Save your time, do it right. :) Some good reading on the subject could be anything about TDD, general articles by Martin Fowler (“Is Design Dead?”, for example) and of course the design patterns material. They aren’t the goal and you shouldn’t aim on using them all the time; they just help you to concentrate on real tasks instead of re-inventing the wheel.

Hope that it’s interesting and even inspiring to someone. :)]]> Fri, 03 Jun 2005 14:50:09 -0400 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-119 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-119
I looked into unit-testing before, but in small/medium-ish companies, with small/medium projects, probably focussed on different things than development, it is hard to get through. But I won’t stop, obviously, and it’s good to have people around with the same opinions.

Cheers,
Matthias]]>
I looked into unit-testing before, but in small/medium-ish companies, with small/medium projects, probably focussed on different things than development, it is hard to get through. But I won’t stop, obviously, and it’s good to have people around with the same opinions.

Cheers,
Matthias]]> Fri, 03 Jun 2005 18:16:10 -0400 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-120 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-120
Anyway, I’m happy that it was useful writing!]]>
Anyway, I’m happy that it was useful writing!]]> Fri, 03 Jun 2005 18:26:33 -0400 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-122 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-122
here’s the article Aleksey was refering to:
is design dead?

I printed it out and will have a read.

cheers.]]>
here’s the article Aleksey was refering to:
is design dead?

I printed it out and will have a read.

cheers.]]> Fri, 03 Jun 2005 18:50:36 -0400 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-123 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-123 Ruby on Rails – it makes MVC and Object/Relational mapping really easy – its already there for you – even in the smallest of projects.

Watch the 10 minute setup video to get the basic idea.]]> Ruby on Rails – it makes MVC and Object/Relational mapping really easy – its already there for you – even in the smallest of projects.

Watch the 10 minute setup video to get the basic idea.]]> Fri, 03 Jun 2005 21:44:37 -0400 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-124 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-124 SimpleTest recently and I’m really coming around to the idea of test driven design. I tried explaining it to Matthias and Pascal a couple of weeks ago but couldn’t think of a good way to really sell it to them. Your suggestion that it helps to modularise and isolate your components is far better than anything I managed to come up with at the time!]]> SimpleTest recently and I’m really coming around to the idea of test driven design. I tried explaining it to Matthias and Pascal a couple of weeks ago but couldn’t think of a good way to really sell it to them. Your suggestion that it helps to modularise and isolate your components is far better than anything I managed to come up with at the time!]]> Sat, 04 Jun 2005 16:49:35 -0400 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-126 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-126 Sat, 04 Jun 2005 17:23:47 -0400 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-128 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-128
Pascal, of course, the evolution should take place. In most cases, you will add something new, but sometimes you will update existing functionality and very rarely remove.

When you add you create the tests suite beforehand again and try to pass it in minimum number of strokes.

When you change, it’s always best if you have a set of short examples of what the functionality does now (your current set of tests as a basis). Basing on this, you update the tests to reflect your required changes. It helps you, right as in the first time, to create a meaningful arch. and experiment with interfaces with stuff beforehand. After that you simply change what you need and you are done.

When you remove something you just don’t need the tests for that scenario any more. So, kill them.

The tests help you and your team to feel confidence about the application. When you were working a week on one module and then gave it to the other developer on your team you can be absolutely sure that he hasn’t broken any bit of code with his changes because your tests, reflecting your requirements for module, still pass. Being confident is a great feeling: you finish your working day in a great mood and, what’s also important, you can give your application to the client in a middle of the night, knowing that every piece of it is tested and proved to work.

From the first glance, it looks like you are wasting the valuable time for writing useless tests which aren’t bringing the value to your clients. It’s not true. (a) The bugs you find are absolutely different from the bugs your clients will find. At least, you will start to ask for excuses, feel sorry and etc. (b) The time you spend on writing tests is nothing against the time you spend on finding the ways to reproduce bugs, track them, fix them, propagate updates and etc. (c) your reputation goes lower and lower with growth of index in your bug tracker. Having less defects is much better than having an excellent skills in bug-fixing.

So, it’s up to you to make test or no. Just remember two rules (my own experience):

Do Not Test Everything—test only what can break or you will be really wasting time. Make the tests to be a part of your process and position it as sort of a game or invent something to make them look more natural.

If Your Tests Never Fail, They Test Nothing—at least make some adjustments to code (if you are writing tests after implementation) to prove to yourself that the tests will fail if anything will go wrong. And… never worry about the failing tests. If test fails, it means that you have caught the bug, which was going to slip into production version if you had no that test. :)

Sorry, if I sounded like having PhD in Testing. It was just my bit of experience in this are and should be treated this way only.]]>
Pascal, of course, the evolution should take place. In most cases, you will add something new, but sometimes you will update existing functionality and very rarely remove.

When you add you create the tests suite beforehand again and try to pass it in minimum number of strokes.

When you change, it’s always best if you have a set of short examples of what the functionality does now (your current set of tests as a basis). Basing on this, you update the tests to reflect your required changes. It helps you, right as in the first time, to create a meaningful arch. and experiment with interfaces with stuff beforehand. After that you simply change what you need and you are done.

When you remove something you just don’t need the tests for that scenario any more. So, kill them.

The tests help you and your team to feel confidence about the application. When you were working a week on one module and then gave it to the other developer on your team you can be absolutely sure that he hasn’t broken any bit of code with his changes because your tests, reflecting your requirements for module, still pass. Being confident is a great feeling: you finish your working day in a great mood and, what’s also important, you can give your application to the client in a middle of the night, knowing that every piece of it is tested and proved to work.

From the first glance, it looks like you are wasting the valuable time for writing useless tests which aren’t bringing the value to your clients. It’s not true. (a) The bugs you find are absolutely different from the bugs your clients will find. At least, you will start to ask for excuses, feel sorry and etc. (b) The time you spend on writing tests is nothing against the time you spend on finding the ways to reproduce bugs, track them, fix them, propagate updates and etc. (c) your reputation goes lower and lower with growth of index in your bug tracker. Having less defects is much better than having an excellent skills in bug-fixing.

So, it’s up to you to make test or no. Just remember two rules (my own experience):

Do Not Test Everything—test only what can break or you will be really wasting time. Make the tests to be a part of your process and position it as sort of a game or invent something to make them look more natural.

If Your Tests Never Fail, They Test Nothing—at least make some adjustments to code (if you are writing tests after implementation) to prove to yourself that the tests will fail if anything will go wrong. And… never worry about the failing tests. If test fails, it means that you have caught the bug, which was going to slip into production version if you had no that test. :)

Sorry, if I sounded like having PhD in Testing. It was just my bit of experience in this are and should be treated this way only.]]> Mon, 06 Jun 2005 09:31:07 -0400 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-148 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-148
Caching is super-easy in RoR and can be added to an entire controller with one line…

MVC is great!]]>
Caching is super-easy in RoR and can be added to an entire controller with one line…

MVC is great!]]> Thu, 16 Jun 2005 05:33:23 -0400 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-535 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-535
And, if in your project the graphic designer is thinking about SQL you have problems…. hehe

by the way, Aleksey is pretty right about TEST as much as you need, but TEST hehe…

And… some interesting thing to ask is, do you have a PHP class with the queries of your system? I hope not… not exactly that! you can have many ideas on what to do with your queries and so on….

cheers]]>
And, if in your project the graphic designer is thinking about SQL you have problems…. hehe

by the way, Aleksey is pretty right about TEST as much as you need, but TEST hehe…

And… some interesting thing to ask is, do you have a PHP class with the queries of your system? I hope not… not exactly that! you can have many ideas on what to do with your queries and so on….

cheers]]> Sat, 15 Apr 2006 14:08:57 -0400 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-538 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-538 I have never succeeded to explain anything server side to a graphic designer, then again, I realised fairly quick that there’s no need. But there is a hell lot of chaotic developers out there, and MVC seems to be an easy entry point into patterns. The advantages of the modular approach are just too obvious.

I’m not sure I understand what you mean by your last paragraph. Do I have a class for sql, as in one, or as in one for every purpose?

I use a couple of classes that form the abstract use of what I’m going to build, like a list class, which I then extend with the purpose class that I need to build. This class will contain SQL.

Recently at the PHP conference UK Derek Rethans gave a nice introduction into EZ components, and I quite liked their DB class, it abstracts SQL really nicely; I might give it a try soon.]]> I have never succeeded to explain anything server side to a graphic designer, then again, I realised fairly quick that there’s no need. But there is a hell lot of chaotic developers out there, and MVC seems to be an easy entry point into patterns. The advantages of the modular approach are just too obvious.

I’m not sure I understand what you mean by your last paragraph. Do I have a class for sql, as in one, or as in one for every purpose?

I use a couple of classes that form the abstract use of what I’m going to build, like a list class, which I then extend with the purpose class that I need to build. This class will contain SQL.

Recently at the PHP conference UK Derek Rethans gave a nice introduction into EZ components, and I quite liked their DB class, it abstracts SQL really nicely; I might give it a try soon.]]> Sun, 16 Apr 2006 09:25:10 -0400 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-1022 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-1022
I used to use something like DB Class and it is a very interesting component that override the idea of keeping your SQL in plain string, which can be very dangerous to enable SQL Injection attacks.

I hope I made myself understood…]]>
I used to use something like DB Class and it is a very interesting component that override the idea of keeping your SQL in plain string, which can be very dangerous to enable SQL Injection attacks.

I hope I made myself understood…]]> Wed, 12 Jul 2006 06:58:00 -0400 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-1153 http://www.contentwithstyle.co.uk/content/mvc-in-smaller-web-applications/#comment-1153 I used to do some dynamic websites with Java, mainly JSP and Servlets working together, and the one thing I really needed there more than in PHP is a mirrored development server. That takes the grievance off uploading a compiled class to the live server which then has a typo.
Using a class that abstracts the whole sql business… I’m not sure about it. Sure, it keeps everything in one place, but at the same time you’ll have all the work to abstract the whole of the SQL language; and that has to look at feel intuitive, too.]]> I used to do some dynamic websites with Java, mainly JSP and Servlets working together, and the one thing I really needed there more than in PHP is a mirrored development server. That takes the grievance off uploading a compiled class to the live server which then has a typo.
Using a class that abstracts the whole sql business… I’m not sure about it. Sure, it keeps everything in one place, but at the same time you’ll have all the work to abstract the whole of the SQL language; and that has to look at feel intuitive, too.]]> Wed, 26 Jul 2006 02:31:27 -0400