[Coders] Rail vs Django

[Eleftherios Garyfallidis]

This is an interesting discussion between Django and Rails. I think it worth reading. 

http://www.quora.com/Which-should-I-learn-Django-or-Rails

:-)

[Eleftherios Garyfallidis]

Kosta? Which tools are you using for web development? 

[Dimitrios Pritsos]

Thanx Eleftherios -

Rails is a Ruby WebSite/Apps-Components Lib and Django is a Python WebSite/Apps-Components Lib.

So I guess it is a mater of Python or Ruby, while PHP is the most popular yet by far. However, PHP it seem to have Great Limitations in the matter of Server Side Resource Efficiency but there are at least 100 engines and CMSs working on PHP.

I guess its a matter of choice whoever I think PHP is on its Sunset while Python and Ruby is on their Sunrise. As for Python vs Ruby in my web-based-research it seems " Ruby on Rail " to be very Fast for web development and " Python with Django " very Simple/Pure/Not-One-Line-Code-Does-it-ALL (in my opinion more versatile in the matter of maintenance for long term projects).

To conclude I think if one want to have an out-of-the-box solution the she/he should follow the PHP/CMS way. If not the its a matter of Flavor Preference.

Cheers!

Dimitrios

[Eleftherios Garyfallidis]

I see that we have many Python ninjas in our group but at the same time all diaspora code is available for free in Ruby. It is a tough call but we have the best person to make the first decisions about this Alexander the Awesome Ninja! :-) However, it would be good to gather some information about useful APIs here.

By the way check this out https://www.joindiaspora.com - code available in github ;-)

Best wishes,

Eleftherios

[Zoumpatianos Konstantinos]

Hello guys! 

I have used both the web frameworks for big applications. To my experience Django is by far better and less "restricting" and I would personally go for that choice if I had to choose between the two. 

But bare in mind that all of them are huge web app frameworks, and as such they do a lot of magic, which most of the times is really resource consuming for a big production environment, I'd go for Django just because most of its magic is restricted in its extremely good admin section, this means that it doesn't get in your way if you don't need it. 

If you have a really complex database model then both of them can make your life so much easier (Rails is doing more magic here).

But why not simply use a barebones ORM framework like storm (https://storm.canonical.com/), a simple templating language, an MVC pattern and a really simple web framework without any mambo jumbo for this?

Key differences:

• Django allows for developer-defined object relational mapping
• Rails also does that, but with a little more automation (which is not always optimal).

• Django has a custom templating language, that does not allow any python code to be run inside the views, one has to write custom tags that are parsed and executed by the templating language (I like that as it takes the ability out of the designers to do anything weird…)
• Rails supports .erb files which are embedded in ruby (ALTHOUGH you can use templating languages such as HAML which is not bad at all, just a bit exotic)

•  As far as extendability, I will have to say that there are more libraries available for rails, although this will not be a problem for the average web app, you can always do a gem install google_places and have a wonderful Google places API in your app.

To me rails is faster to get you going (for a prototype) but harder to maintain and build a scalable system on it, django is good enough to get you started + scale. But in any case if the complexity of an application lies beyond what is a "simple/standard" website then maybe a custom solution is better.

One company that I know use rails for the frontend but for every kind of serious jobs they have a web services architecture running on twisted/python.

But always key questions are what do other people with similar apps use. How complex is the application, what tools are available and in which language/framework. etc.

i hope this helps a bit,

Cheers,

Kostas 

[Eleftherios Garyfallidis]

Great post Kostas. It does help a lot indeed. Storm looks very interesting :-) 

Alex?

[Dimitrios Pritsos]

It seems the Stuff I ve read so far plus some review to the Django book recently I ve acquired agrees to Kostas Experience. (Thanx Kostas)

YES, MVC it should be there in any Architect we might use.

There is a problem going from scratch if you want to go fast, eventhought some times for example for Ajax stuff is better to do it with basic custom libs instead of JQuerry or other Ajax lib. But in our case I think that there are lots of staff required as prerequisite to go from scratch. �

So Lets go Django. I will do that anyway for transferring my Web Site from PHP-Joomla/Virtuemart/+1k-of-Hacks to Django/Satchmo-Python. So I can work for both and gain experience faster.

((( There is Satchmo Project on Django Engine for E-Commenrce in case you do interested Kostas, it just an extension of Django and not a fork i.e. it goes better as Django goes better giving the basics to build an ecommerce fast!� - http://www.satchmoproject.com/ )))

Twisted is a lib mainly for building fast a Network App with Threading/Multiprocessing stuff built-in.

Cheers to all!


On 02/15/2012 01:46 PM, Eleftherios Garyfallidis wrote:

Great post Kostas. It does help a lot indeed. Storm looks very interesting :-)�

Alex?

On Wed, Feb 15, 2012 at 11:25 AM, Zoumpatianos Konstantinos <zoumpa...@disi.unitn.it> wrote:

Hello guys!�

I have used both the web frameworks for big applications. To my experience Django is by far better and less "restricting" and I would personally go for that choice if I had to choose between the two.�

But bare in mind that all of them are huge web app frameworks, and as such they do a lot of magic, which most of the times is really resource consuming for a big production environment, I'd go for Django just because most of its magic is restricted in its extremely good admin section, this means that it doesn't get in your way if you don't need it.�

If you have a really complex database model then both of them can make your life so much easier (Rails is doing more magic here).

But why not simply use a barebones ORM framework like storm (https://storm.canonical.com/), a simple templating language, an MVC pattern and a really simple web framework without any mambo jumbo for this?

Key differences:

• Django allows for developer-defined object relational mapping
• Rails also does that, but with a little more automation (which is not always optimal).

• Django has a custom templating language, that does not allow any python code to be run inside the views, one has to write custom tags that are parsed and executed by the templating language (I like that as it takes the ability out of the designers to do anything weird�)

• Rails supports .erb files which are embedded in ruby (ALTHOUGH you can use templating languages such as HAML which is not bad at all, just a bit exotic)

• �As far as extendability, I will have to say that there are more libraries available for rails, although this will not be a problem for the average web app, you can always do a gem install google_places and have a wonderful Google places API in your app.

To me rails is faster to get you going (for a prototype) but harder to maintain and build a scalable system on it, django is good enough to get you started + scale. But in any case if the complexity of an application lies beyond what is a "simple/standard" website then maybe a custom solution is better.

One company that I know use rails for the frontend but for every kind of serious jobs they have a web services architecture running on twisted/python.

But always key questions are what do other people with similar apps use. How complex is the application, what tools are available and in which language/framework. etc.

i hope this helps a bit,

Cheers,

Kostas�

�

On Wed, Feb 15, 2012 at 10:38 AM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

Thanx Eleftherios -

Rails is a Ruby WebSite/Apps-Components Lib and Django is a Python WebSite/Apps-Components Lib.

So I guess it is a mater of Python or Ruby, while PHP is the most popular yet by far. However, PHP it seem to have Great Limitations in the matter of Server Side Resource Efficiency but there are at least 100 engines and CMSs working on PHP.

I guess its a matter of choice whoever I think PHP is on its Sunset while Python and Ruby is on their Sunrise. As for Python vs Ruby in my web-based-research it seems " Ruby on Rail " to be very Fast for web development and " Python with Django " very Simple/Pure/Not-One-Line-Code-Does-it-ALL (in my opinion more versatile in the matter of maintenance for long term projects).

To conclude I think if one want to have an out-of-the-box solution the she/he should follow the PHP/CMS way. If not the its a matter of Flavor Preference.

Cheers!

Dimitrios

On 02/15/2012 03:02 AM, Eleftherios Garyfallidis wrote:

This is an interesting discussion between Django and Rails. I think it worth reading.�

http://www.quora.com/Which-should-I-learn-Django-or-Rails

:-)

[Eleftherios Garyfallidis]

Lets not decide immediately. I was talking with Alex yesterday on the phone. I think he will have some good suggestions too - even the possibility to build this peer-to-peer. He is most experienced than all of us so he should lead the design in the beginning and then we can start contribute. But yeah Django seems better than I was expecting - but do all servers (Apache) support it?

On Wed, Feb 15, 2012 at 1:24 PM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

It seems the Stuff I ve read so far plus some review to the Django book recently I ve acquired agrees to Kostas Experience. (Thanx Kostas)

YES, MVC it should be there in any Architect we might use.

There is a problem going from scratch if you want to go fast, eventhought some times for example for Ajax stuff is better to do it with basic custom libs instead of JQuerry or other Ajax lib. But in our case I think that there are lots of staff required as prerequisite to go from scratch.  

So Lets go Django. I will do that anyway for transferring my Web Site from PHP-Joomla/Virtuemart/+1k-of-Hacks to Django/Satchmo-Python. So I can work for both and gain experience faster.

((( There is Satchmo Project on Django Engine for E-Commenrce in case you do interested Kostas, it just an extension of Django and not a fork i.e. it goes better as Django goes better giving the basics to build an ecommerce fast!  - http://www.satchmoproject.com/ )))

Twisted is a lib mainly for building fast a Network App with Threading/Multiprocessing stuff built-in.

Cheers to all!

On 02/15/2012 01:46 PM, Eleftherios Garyfallidis wrote:

Great post Kostas. It does help a lot indeed. Storm looks very interesting :-) 

Alex?

On Wed, Feb 15, 2012 at 11:25 AM, Zoumpatianos Konstantinos <zoumpa...@disi.unitn.it> wrote:

Hello guys! 

I have used both the web frameworks for big applications. To my experience Django is by far better and less "restricting" and I would personally go for that choice if I had to choose between the two. 

But bare in mind that all of them are huge web app frameworks, and as such they do a lot of magic, which most of the times is really resource consuming for a big production environment, I'd go for Django just because most of its magic is restricted in its extremely good admin section, this means that it doesn't get in your way if you don't need it. 

If you have a really complex database model then both of them can make your life so much easier (Rails is doing more magic here).

But why not simply use a barebones ORM framework like storm (https://storm.canonical.com/), a simple templating language, an MVC pattern and a really simple web framework without any mambo jumbo for this?

Key differences:

• Django allows for developer-defined object relational mapping
• Rails also does that, but with a little more automation (which is not always optimal).

• Django has a custom templating language, that does not allow any python code to be run inside the views, one has to write custom tags that are parsed and executed by the templating language (I like that as it takes the ability out of the designers to do anything weird…)

• Rails supports .erb files which are embedded in ruby (ALTHOUGH you can use templating languages such as HAML which is not bad at all, just a bit exotic)

•  As far as extendability, I will have to say that there are more libraries available for rails, although this will not be a problem for the average web app, you can always do a gem install google_places and have a wonderful Google places API in your app.

To me rails is faster to get you going (for a prototype) but harder to maintain and build a scalable system on it, django is good enough to get you started + scale. But in any case if the complexity of an application lies beyond what is a "simple/standard" website then maybe a custom solution is better.

One company that I know use rails for the frontend but for every kind of serious jobs they have a web services architecture running on twisted/python.

But always key questions are what do other people with similar apps use. How complex is the application, what tools are available and in which language/framework. etc.

i hope this helps a bit,

Cheers,

Kostas 

On Wed, Feb 15, 2012 at 10:38 AM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

Thanx Eleftherios -

Rails is a Ruby WebSite/Apps-Components Lib and Django is a Python WebSite/Apps-Components Lib.

So I guess it is a mater of Python or Ruby, while PHP is the most popular yet by far. However, PHP it seem to have Great Limitations in the matter of Server Side Resource Efficiency but there are at least 100 engines and CMSs working on PHP.

I guess its a matter of choice whoever I think PHP is on its Sunset while Python and Ruby is on their Sunrise. As for Python vs Ruby in my web-based-research it seems " Ruby on Rail " to be very Fast for web development and " Python with Django " very Simple/Pure/Not-One-Line-Code-Does-it-ALL (in my opinion more versatile in the matter of maintenance for long term projects).

To conclude I think if one want to have an out-of-the-box solution the she/he should follow the PHP/CMS way. If not the its a matter of Flavor Preference.

Cheers!

Dimitrios

On 02/15/2012 03:02 AM, Eleftherios Garyfallidis wrote:

This is an interesting discussion between Django and Rails. I think it worth reading. 

http://www.quora.com/Which-should-I-learn-Django-or-Rails

:-)

[Dimitrios Pritsos]

They do, however there are some Variations on the way they do! but this is the case even for PHP or some PHP version so Hosting won't be a problem if that what your asking.

The optimal Solution on my opintion is to use the Ready Made staff out there as for Interfacing and some Ajax FX that increased the Usabilty. However, The CORE engine should be on a Lib that can be discarded in the Future however it give us all the Prerequisites to work Fast.

I think "You never Know Until You do it". So Let NOT SPEND the time on Design that will not be followed in the future.

I ve redesigned re-implement 3 times My very simple Lib for my PhD and still needs changes to all my intial plans.

I don't know, Your Call!

On 02/15/2012 03:30 PM, Eleftherios Garyfallidis wrote:

Lets not decide immediately. I was talking with Alex yesterday on the phone. I think he will have some good suggestions too - even the possibility to build this peer-to-peer. He is most experienced than all of us so he should lead the design in the beginning and then we can start contribute. But yeah Django seems better than I was expecting - but do all servers (Apache) support it?

On Wed, Feb 15, 2012 at 1:24 PM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

It seems the Stuff I ve read so far plus some review to the Django book recently I ve acquired agrees to Kostas Experience. (Thanx Kostas)

YES, MVC it should be there in any Architect we might use.

There is a problem going from scratch if you want to go fast, eventhought some times for example for Ajax stuff is better to do it with basic custom libs instead of JQuerry or other Ajax lib. But in our case I think that there are lots of staff required as prerequisite to go from scratch. �

So Lets go Django. I will do that anyway for transferring my Web Site from PHP-Joomla/Virtuemart/+1k-of-Hacks to Django/Satchmo-Python. So I can work for both and gain experience faster.

((( There is Satchmo Project on Django Engine for E-Commenrce in case you do interested Kostas, it just an extension of Django and not a fork i.e. it goes better as Django goes better giving the basics to build an ecommerce fast!� - http://www.satchmoproject.com/ )))

Twisted is a lib mainly for building fast a Network App with Threading/Multiprocessing stuff built-in.

Cheers to all!

On 02/15/2012 01:46 PM, Eleftherios Garyfallidis wrote:

Great post Kostas. It does help a lot indeed. Storm looks very interesting :-)�

Alex?

On Wed, Feb 15, 2012 at 11:25 AM, Zoumpatianos Konstantinos <zoumpa...@disi.unitn.it> wrote:

Hello guys!�

I have used both the web frameworks for big applications. To my experience Django is by far better and less "restricting" and I would personally go for that choice if I had to choose between the two.�

But bare in mind that all of them are huge web app frameworks, and as such they do a lot of magic, which most of the times is really resource consuming for a big production environment, I'd go for Django just because most of its magic is restricted in its extremely good admin section, this means that it doesn't get in your way if you don't need it.�

If you have a really complex database model then both of them can make your life so much easier (Rails is doing more magic here).

But why not simply use a barebones ORM framework like storm (https://storm.canonical.com/), a simple templating language, an MVC pattern and a really simple web framework without any mambo jumbo for this?

Key differences:

• Django allows for developer-defined object relational mapping
• Rails also does that, but with a little more automation (which is not always optimal).

• Django has a custom templating language, that does not allow any python code to be run inside the views, one has to write custom tags that are parsed and executed by the templating language (I like that as it takes the ability out of the designers to do anything weird�)

• Rails supports .erb files which are embedded in ruby (ALTHOUGH you can use templating languages such as HAML which is not bad at all, just a bit exotic)

• �As far as extendability, I will have to say that there are more libraries available for rails, although this will not be a problem for the average web app, you can always do a gem install google_places and have a wonderful Google places API in your app.

To me rails is faster to get you going (for a prototype) but harder to maintain and build a scalable system on it, django is good enough to get you started + scale. But in any case if the complexity of an application lies beyond what is a "simple/standard" website then maybe a custom solution is better.

One company that I know use rails for the frontend but for every kind of serious jobs they have a web services architecture running on twisted/python.

But always key questions are what do other people with similar apps use. How complex is the application, what tools are available and in which language/framework. etc.

i hope this helps a bit,

Cheers,

Kostas�

�

On Wed, Feb 15, 2012 at 10:38 AM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

Thanx Eleftherios -

Rails is a Ruby WebSite/Apps-Components Lib and Django is a Python WebSite/Apps-Components Lib.

So I guess it is a mater of Python or Ruby, while PHP is the most popular yet by far. However, PHP it seem to have Great Limitations in the matter of Server Side Resource Efficiency but there are at least 100 engines and CMSs working on PHP.

I guess its a matter of choice whoever I think PHP is on its Sunset while Python and Ruby is on their Sunrise. As for Python vs Ruby in my web-based-research it seems " Ruby on Rail " to be very Fast for web development and " Python with Django " very Simple/Pure/Not-One-Line-Code-Does-it-ALL (in my opinion more versatile in the matter of maintenance for long term projects).

To conclude I think if one want to have an out-of-the-box solution the she/he should follow the PHP/CMS way. If not the its a matter of Flavor Preference.

Cheers!

Dimitrios

On 02/15/2012 03:02 AM, Eleftherios Garyfallidis wrote:

This is an interesting discussion between Django and Rails. I think it worth reading.�

http://www.quora.com/Which-should-I-learn-Django-or-Rails

:-)

[Alexandros]

I have no problem with doing it in Django, or Ruby, the problem is that I have no experience on those and it will take some time to learn (however I always love learning new technologies :D )

on the other hand I'd like us to check out node.js a bit (where javascript is used throught the client side and the server side) , the one our "technical mentor" suggested over at the Startup Weekend. It seems quite promising...

Concerning the P2P. I would also like your suggestions guys. If we are to build this social tool with  the prospects of having a big social impact, especially if we go the non-profit way, we might want to go with a decentralized architecture (we can either do it the Diaspora way, or in more traditional P2P ways), one that would ensure user privacy and service independence 

What are your thoughts on that?

[Eleftherios Garyfallidis]

Alex Kostas suggested storm.canonical.com. That looks very interesting too. What is your take on that?

On Wed, Feb 15, 2012 at 3:30 PM, Alexandros <atria...@gmail.com> wrote:

I have no problem with doing it in Django, or Ruby, the problem is that I have no experience on those and it will take some time to learn (however I always love learning new technologies :D )

on the other hand I'd like us to check out node.js a bit (where javascript is used throught the client side and the server side) , the one our "technical mentor" suggested over at the Startup Weekend. It seems quite promising...

Yes, I do remember that. 

 

Concerning the P2P. I would also like your suggestions guys. If we are to build this social tool with  the prospects of having a big social impact, especially if we go the non-profit way, we might want to go with a decentralized architecture (we can either do it the Diaspora way, or in more traditional P2P ways), one that would ensure user privacy and service independence 

What are your thoughts on that?

 It is great to be independent. However, it might need more research to implement the P2P. Should we live it for future work? But apply good OO strategies so that the jump is not on the impossible side.

Kostas? Panagiotis? Any ideas? What about the developers you met in the startup? Any feedback from them? Inviting to the list would be useful too. 

Cheers,

Eleftherios

Offtopic: Have a look at the number of sponsors in PyCon this year https://us.pycon.org/2012/sponsors . Crazy!!! Even Microsoft got involved.

[Zoumpatianos Konstantinos]

NodeJS sounds really promising and there is a lot of buzz around it recently. Apparently there is also a good codebase for that: https://github.com/joyent/node/wiki/modules.

If this is going to be a distributes collaborative system then real time communication between node<->node and node<->browser in a publish subscribe or similar fashion is crucial. A project that is also very promising and worths to take a look at: http://www.ape-project.org/.

I am sure though that you can write comet services with nodejs too.

NodeJS is extendable via JS or C++ which is cool.

K.

[Zoumpatianos Konstantinos]

My personal approach is always to distribute. No need to stick to one language, one platform, one technology. You can build different parts of the system in different languages and stick them together. E.g. a web services based architecture.

The more independent each module is and the more clearly (and technology independent) its interface is defined then the best it is. I still haven't worked for a project where a module didn't change or even got re-written from scratch. 

I think the first part is to break down the system into modules. Identify the requirements for each module and their interconnections and then see what is appropriate, also taking into consideration the current knowledge of the team/resources + time.

Key questions:

- What are the backend requirements also considering the long term targets?

- What is the data model, how complex is it? Does it have a rich schema or not (nosql or sql and where)?

- How complex the user interface should be, how should it interact with the backend?

- Is the backend complex enough or is it simple enough and can be tightly coupled with the front-end?

- Is there a need of multiple backends collaborating with each other 

- Which modules could have performance issues?

[Dimitrios Pritsos]

ΟΚ Ι ll need to check NodeJS and let you know what I think.

In any case I think, whatever path you will follow there is alway a Significant amount of Learning Curve.

In most P2P Scenario I have seen there is always need for SuperNodes and staff like that so P2P is re quires Some sort of Servers just with Different name ie SuperNodes. It just you don't need for a DataCenter. This is the case of Diaspora.

However, since it is going to be for Production and not just for Fun then we should follow a set of tools that you can remove them of use them partially and not depend on them. CMSs I have tried so far has the problem make you depended on these tools and do simple things with had way. In addition, the Core engine should be so basic so we will be able to do "LowLevel" Staff without being forced to change the Core it self and Discard it eventually if this is our Goal. This is what Django is Promising.

Have anyone use any of these tools for real production projects?

My Experience is that PHP is not scalable and recored lots of Apache modules to improving efficiency. I have even needed to employee several Tricks an Patches to my Site just for Decries my CPU Usage on the Server. In addition I need to pay handres of Euros per year just for hosting because PHP is a Wild Beast eating the CPU. Of course this has to do with the Joomla, however, I don't know any PHP CMS for really demanding Web sites where Scaling is required (I think only Magento does but not sure).

What is the case for the rest of the tools we are discussing here? and NodeJS. Django it suppose to be ready for great Scaling (But I don't know because I haven't Use it) anyone knows?

Cheers!

Mitsos

�




On 02/15/2012 06:02 PM, Zoumpatianos Konstantinos wrote:

NodeJS sounds really promising and there is a lot of buzz around it recently. Apparently there is also a good codebase for that:�https://github.com/joyent/node/wiki/modules.

If this is going to be a distributes collaborative system then real time communication between node<->node and node<->browser in a publish subscribe or similar fashion is crucial. A project that is also very promising and worths to take a look at:�http://www.ape-project.org/.

I am sure though that you can write comet services with nodejs too.

NodeJS is extendable via JS or C++ which is cool.

K.

On Wed, Feb 15, 2012 at 4:30 PM, Alexandros <atria...@gmail.com> wrote:

I have no problem with doing it in Django, or Ruby, the problem is that I have no experience on those and it will take some time to learn (however I always love learning new technologies :D )

on the other hand I'd like us to check out node.js a bit (where javascript is used throught the client side and the server side) , the one our "technical mentor" suggested over at the Startup Weekend. It seems quite promising...

Concerning the P2P. I would also like your suggestions guys. If we are to build this social tool with �the prospects of having a big social impact, especially if we go the non-profit way, we might want to go with a decentralized architecture (we can either do it the Diaspora way, or in more traditional P2P ways), one that would ensure user privacy and service independence�

What are your thoughts on that?

On Wed, Feb 15, 2012 at 3:30 PM, Eleftherios Garyfallidis <garyfa...@gmail.com> wrote:

Lets not decide immediately. I was talking with Alex yesterday on the phone. I think he will have some good suggestions too - even the possibility to build this peer-to-peer. He is most experienced than all of us so he should lead the design in the beginning and then we can start contribute. But yeah Django seems better than I was expecting - but do all servers (Apache) support it?

On Wed, Feb 15, 2012 at 1:24 PM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

It seems the Stuff I ve read so far plus some review to the Django book recently I ve acquired agrees to Kostas Experience. (Thanx Kostas)

YES, MVC it should be there in any Architect we might use.

There is a problem going from scratch if you want to go fast, eventhought some times for example for Ajax stuff is better to do it with basic custom libs instead of JQuerry or other Ajax lib. But in our case I think that there are lots of staff required as prerequisite to go from scratch. �

So Lets go Django. I will do that anyway for transferring my Web Site from PHP-Joomla/Virtuemart/+1k-of-Hacks to Django/Satchmo-Python. So I can work for both and gain experience faster.

((( There is Satchmo Project on Django Engine for E-Commenrce in case you do interested Kostas, it just an extension of Django and not a fork i.e. it goes better as Django goes better giving the basics to build an ecommerce fast!� - http://www.satchmoproject.com/ )))

Twisted is a lib mainly for building fast a Network App with Threading/Multiprocessing stuff built-in.

Cheers to all!

On 02/15/2012 01:46 PM, Eleftherios Garyfallidis wrote:

Great post Kostas. It does help a lot indeed. Storm looks very interesting :-)�

Alex?

On Wed, Feb 15, 2012 at 11:25 AM, Zoumpatianos Konstantinos <zoumpa...@disi.unitn.it> wrote:

Hello guys!�

I have used both the web frameworks for big applications. To my experience Django is by far better and less "restricting" and I would personally go for that choice if I had to choose between the two.�

But bare in mind that all of them are huge web app frameworks, and as such they do a lot of magic, which most of the times is really resource consuming for a big production environment, I'd go for Django just because most of its magic is restricted in its extremely good admin section, this means that it doesn't get in your way if you don't need it.�

If you have a really complex database model then both of them can make your life so much easier (Rails is doing more magic here).

But why not simply use a barebones ORM framework like storm (https://storm.canonical.com/), a simple templating language, an MVC pattern and a really simple web framework without any mambo jumbo for this?

Key differences:

• Django allows for developer-defined object relational mapping
• Rails also does that, but with a little more automation (which is not always optimal).

• Django has a custom templating language, that does not allow any python code to be run inside the views, one has to write custom tags that are parsed and executed by the templating language (I like that as it takes the ability out of the designers to do anything weird�)

• Rails supports .erb files which are embedded in ruby (ALTHOUGH you can use templating languages such as HAML which is not bad at all, just a bit exotic)

• �As far as extendability, I will have to say that there are more libraries available for rails, although this will not be a problem for the average web app, you can always do a gem install google_places and have a wonderful Google places API in your app.

To me rails is faster to get you going (for a prototype) but harder to maintain and build a scalable system on it, django is good enough to get you started + scale. But in any case if the complexity of an application lies beyond what is a "simple/standard" website then maybe a custom solution is better.

One company that I know use rails for the frontend but for every kind of serious jobs they have a web services architecture running on twisted/python.

But always key questions are what do other people with similar apps use. How complex is the application, what tools are available and in which language/framework. etc.

i hope this helps a bit,

Cheers,

Kostas�

�

On Wed, Feb 15, 2012 at 10:38 AM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

Thanx Eleftherios -

Rails is a Ruby WebSite/Apps-Components Lib and Django is a Python WebSite/Apps-Components Lib.

So I guess it is a mater of Python or Ruby, while PHP is the most popular yet by far. However, PHP it seem to have Great Limitations in the matter of Server Side Resource Efficiency but there are at least 100 engines and CMSs working on PHP.

I guess its a matter of choice whoever I think PHP is on its Sunset while Python and Ruby is on their Sunrise. As for Python vs Ruby in my web-based-research it seems " Ruby on Rail " to be very Fast for web development and " Python with Django " very Simple/Pure/Not-One-Line-Code-Does-it-ALL (in my opinion more versatile in the matter of maintenance for long term projects).

To conclude I think if one want to have an out-of-the-box solution the she/he should follow the PHP/CMS way. If not the its a matter of Flavor Preference.

Cheers!

Dimitrios

On 02/15/2012 03:02 AM, Eleftherios Garyfallidis wrote:

This is an interesting discussion between Django and Rails. I think it worth reading.�

http://www.quora.com/Which-should-I-learn-Django-or-Rails

:-)

[Dimitrios Pritsos]

On 02/15/2012 06:32 PM, Zoumpatianos Konstantinos wrote:

My personal approach is always to distribute. No need to stick to one language, one platform, one technology. You can build different parts of the system in different languages and stick them together. E.g. a web services based architecture.

Yes this it the best solution, however, we need to start from something

The more independent each module is and the more clearly (and technology independent) its interface is defined then the best it is. I still haven't worked for a project where a module didn't change or even got re-written from scratch.

Exactly that is why we have to use Core Engines that can be Discard when need there is need for it

I think the first part is to break down the system into modules. Identify the requirements for each module and their interconnections and then see what is appropriate, also taking into consideration the current knowledge of the team/resources + time.

Key questions:

- What are the backend requirements also considering the long term targets?

- What is the data model, how complex is it? Does it have a rich schema or not (nosql or sql and where)?

- How complex the user interface should be, how should it interact with the backend?

- Is the backend complex enough or is it simple enough and can be tightly coupled with the front-end?

- Is there a need of multiple backends collaborating with each other�

- Which modules could have performance issues?

I think we should build a our Core Engine and we will see in the process because we simply don't know yet. So In the context of Design we should follow an Spiral (Design-Implement-ReDeding-Reimplement-etc).

Eletherios, I think we might need Dimitriadis Expeties on Software Development Models� and Project Managment

On Wed, Feb 15, 2012 at 5:02 PM, Zoumpatianos Konstantinos <zoumpa...@disi.unitn.it> wrote:

NodeJS sounds really promising and there is a lot of buzz around it recently. Apparently there is also a good codebase for that:�https://github.com/joyent/node/wiki/modules.

If this is going to be a distributes collaborative system then real time communication between node<->node and node<->browser in a publish subscribe or similar fashion is crucial. A project that is also very promising and worths to take a look at:�http://www.ape-project.org/.

I am sure though that you can write comet services with nodejs too.

NodeJS is extendable via JS or C++ which is cool.

K.

On Wed, Feb 15, 2012 at 4:30 PM, Alexandros <atria...@gmail.com> wrote:

I have no problem with doing it in Django, or Ruby, the problem is that I have no experience on those and it will take some time to learn (however I always love learning new technologies :D )

on the other hand I'd like us to check out node.js a bit (where javascript is used throught the client side and the server side) , the one our "technical mentor" suggested over at the Startup Weekend. It seems quite promising...

Concerning the P2P. I would also like your suggestions guys. If we are to build this social tool with �the prospects of having a big social impact, especially if we go the non-profit way, we might want to go with a decentralized architecture (we can either do it the Diaspora way, or in more traditional P2P ways), one that would ensure user privacy and service independence�

What are your thoughts on that?

On Wed, Feb 15, 2012 at 3:30 PM, Eleftherios Garyfallidis <garyfa...@gmail.com> wrote:

Lets not decide immediately. I was talking with Alex yesterday on the phone. I think he will have some good suggestions too - even the possibility to build this peer-to-peer. He is most experienced than all of us so he should lead the design in the beginning and then we can start contribute. But yeah Django seems better than I was expecting - but do all servers (Apache) support it?

On Wed, Feb 15, 2012 at 1:24 PM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

It seems the Stuff I ve read so far plus some review to the Django book recently I ve acquired agrees to Kostas Experience. (Thanx Kostas)

YES, MVC it should be there in any Architect we might use.

There is a problem going from scratch if you want to go fast, eventhought some times for example for Ajax stuff is better to do it with basic custom libs instead of JQuerry or other Ajax lib. But in our case I think that there are lots of staff required as prerequisite to go from scratch. �

So Lets go Django. I will do that anyway for transferring my Web Site from PHP-Joomla/Virtuemart/+1k-of-Hacks to Django/Satchmo-Python. So I can work for both and gain experience faster.

((( There is Satchmo Project on Django Engine for E-Commenrce in case you do interested Kostas, it just an extension of Django and not a fork i.e. it goes better as Django goes better giving the basics to build an ecommerce fast!� - http://www.satchmoproject.com/ )))

Twisted is a lib mainly for building fast a Network App with Threading/Multiprocessing stuff built-in.

Cheers to all!

On 02/15/2012 01:46 PM, Eleftherios Garyfallidis wrote:

Great post Kostas. It does help a lot indeed. Storm looks very interesting :-)�

Alex?

On Wed, Feb 15, 2012 at 11:25 AM, Zoumpatianos Konstantinos <zoumpa...@disi.unitn.it> wrote:

Hello guys!�

I have used both the web frameworks for big applications. To my experience Django is by far better and less "restricting" and I would personally go for that choice if I had to choose between the two.�

But bare in mind that all of them are huge web app frameworks, and as such they do a lot of magic, which most of the times is really resource consuming for a big production environment, I'd go for Django just because most of its magic is restricted in its extremely good admin section, this means that it doesn't get in your way if you don't need it.�

If you have a really complex database model then both of them can make your life so much easier (Rails is doing more magic here).

But why not simply use a barebones ORM framework like storm (https://storm.canonical.com/), a simple templating language, an MVC pattern and a really simple web framework without any mambo jumbo for this?

Key differences:

• Django allows for developer-defined object relational mapping
• Rails also does that, but with a little more automation (which is not always optimal).

• Django has a custom templating language, that does not allow any python code to be run inside the views, one has to write custom tags that are parsed and executed by the templating language (I like that as it takes the ability out of the designers to do anything weird�)

• Rails supports .erb files which are embedded in ruby (ALTHOUGH you can use templating languages such as HAML which is not bad at all, just a bit exotic)

• �As far as extendability, I will have to say that there are more libraries available for rails, although this will not be a problem for the average web app, you can always do a gem install google_places and have a wonderful Google places API in your app.

To me rails is faster to get you going (for a prototype) but harder to maintain and build a scalable system on it, django is good enough to get you started + scale. But in any case if the complexity of an application lies beyond what is a "simple/standard" website then maybe a custom solution is better.

One company that I know use rails for the frontend but for every kind of serious jobs they have a web services architecture running on twisted/python.

But always key questions are what do other people with similar apps use. How complex is the application, what tools are available and in which language/framework. etc.

i hope this helps a bit,

Cheers,

Kostas�

�

On Wed, Feb 15, 2012 at 10:38 AM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

Thanx Eleftherios -

Rails is a Ruby WebSite/Apps-Components Lib and Django is a Python WebSite/Apps-Components Lib.

So I guess it is a mater of Python or Ruby, while PHP is the most popular yet by far. However, PHP it seem to have Great Limitations in the matter of Server Side Resource Efficiency but there are at least 100 engines and CMSs working on PHP.

I guess its a matter of choice whoever I think PHP is on its Sunset while Python and Ruby is on their Sunrise. As for Python vs Ruby in my web-based-research it seems " Ruby on Rail " to be very Fast for web development and " Python with Django " very Simple/Pure/Not-One-Line-Code-Does-it-ALL (in my opinion more versatile in the matter of maintenance for long term projects).

To conclude I think if one want to have an out-of-the-box solution the she/he should follow the PHP/CMS way. If not the its a matter of Flavor Preference.

Cheers!

Dimitrios

On 02/15/2012 03:02 AM, Eleftherios Garyfallidis wrote:

This is an interesting discussion between Django and Rails. I think it worth reading.�

http://www.quora.com/Which-should-I-learn-Django-or-Rails

:-)

[Zoumpatianos Konstantinos]

I have used rails in production and it does not scale well. But it all depends on the kind of code you write and the libraries you use and the experience you have 99% of the new developers will write inefficient code. PHP has the problem that it is poorly designed but can run fast in certain cases. 

For rails there is a mod_rails for apache now which makes life easier, 4 years ago when I've been using rails you had to spawn multiple ruby web servers and load balance between them. This is good for one computer but you need a distributed sessions mechanism for multiple machines.

The best combination I've seen so far was Python/C++ for the backend, creating web services consumed by a really lightweight rails front-end (no complex stuff done in the front-end).

Django is good and there are companies who have scaled with that, I've used it for internal applications and marketing  style websites, so no real traffic.

But after all it all comes down to:

• Database calls, avoiding complex and repetitive queries
• Caching 
• Removing unwanted complexity on simple operations (magic stuff added by frameworks).

My worst experience was with CakePHP, what a mess… 

This is the problem of complex frameworks, you start with a lot of complexity and you have to remove it gradually. On the other hand custom solutions start with no complexity and you have to add it.

CMSs and big community apps also have huge complexity and overhead, I wrote an extension for mediawiki in the past and I wanted to kill my self brutally. 

Generally python is fast, faster than ruby and php, it can be easily extended via C++, it is simple and there are a lot of good developers around. 

On Wed, Feb 15, 2012 at 5:48 PM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

ΟΚ Ι ll need to check NodeJS and let you know what I think.

In any case I think, whatever path you will follow there is alway a Significant amount of Learning Curve.

In most P2P Scenario I have seen there is always need for SuperNodes and staff like that so P2P is re quires Some sort of Servers just with Different name ie SuperNodes. It just you don't need for a DataCenter. This is the case of Diaspora.

However, since it is going to be for Production and not just for Fun then we should follow a set of tools that you can remove them of use them partially and not depend on them. CMSs I have tried so far has the problem make you depended on these tools and do simple things with had way. In addition, the Core engine should be so basic so we will be able to do "LowLevel" Staff without being forced to change the Core it self and Discard it eventually if this is our Goal. This is what Django is Promising.

Have anyone use any of these tools for real production projects?

My Experience is that PHP is not scalable and recored lots of Apache modules to improving efficiency. I have even needed to employee several Tricks an Patches to my Site just for Decries my CPU Usage on the Server. In addition I need to pay handres of Euros per year just for hosting because PHP is a Wild Beast eating the CPU. Of course this has to do with the Joomla, however, I don't know any PHP CMS for really demanding Web sites where Scaling is required (I think only Magento does but not sure).

What is the case for the rest of the tools we are discussing here? and NodeJS. Django it suppose to be ready for great Scaling (But I don't know because I haven't Use it) anyone knows?

Cheers!

Mitsos

On 02/15/2012 06:02 PM, Zoumpatianos Konstantinos wrote:

NodeJS sounds really promising and there is a lot of buzz around it recently. Apparently there is also a good codebase for that: https://github.com/joyent/node/wiki/modules.

If this is going to be a distributes collaborative system then real time communication between node<->node and node<->browser in a publish subscribe or similar fashion is crucial. A project that is also very promising and worths to take a look at: http://www.ape-project.org/.

I am sure though that you can write comet services with nodejs too.

NodeJS is extendable via JS or C++ which is cool.

K.

On Wed, Feb 15, 2012 at 4:30 PM, Alexandros <atria...@gmail.com> wrote:

I have no problem with doing it in Django, or Ruby, the problem is that I have no experience on those and it will take some time to learn (however I always love learning new technologies :D )

on the other hand I'd like us to check out node.js a bit (where javascript is used throught the client side and the server side) , the one our "technical mentor" suggested over at the Startup Weekend. It seems quite promising...

Concerning the P2P. I would also like your suggestions guys. If we are to build this social tool with  the prospects of having a big social impact, especially if we go the non-profit way, we might want to go with a decentralized architecture (we can either do it the Diaspora way, or in more traditional P2P ways), one that would ensure user privacy and service independence 

What are your thoughts on that?

On Wed, Feb 15, 2012 at 3:30 PM, Eleftherios Garyfallidis <garyfa...@gmail.com> wrote:

Lets not decide immediately. I was talking with Alex yesterday on the phone. I think he will have some good suggestions too - even the possibility to build this peer-to-peer. He is most experienced than all of us so he should lead the design in the beginning and then we can start contribute. But yeah Django seems better than I was expecting - but do all servers (Apache) support it?

On Wed, Feb 15, 2012 at 1:24 PM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

It seems the Stuff I ve read so far plus some review to the Django book recently I ve acquired agrees to Kostas Experience. (Thanx Kostas)

YES, MVC it should be there in any Architect we might use.

There is a problem going from scratch if you want to go fast, eventhought some times for example for Ajax stuff is better to do it with basic custom libs instead of JQuerry or other Ajax lib. But in our case I think that there are lots of staff required as prerequisite to go from scratch.  

So Lets go Django. I will do that anyway for transferring my Web Site from PHP-Joomla/Virtuemart/+1k-of-Hacks to Django/Satchmo-Python. So I can work for both and gain experience faster.

((( There is Satchmo Project on Django Engine for E-Commenrce in case you do interested Kostas, it just an extension of Django and not a fork i.e. it goes better as Django goes better giving the basics to build an ecommerce fast!  - http://www.satchmoproject.com/ )))

Twisted is a lib mainly for building fast a Network App with Threading/Multiprocessing stuff built-in.

Cheers to all!

On 02/15/2012 01:46 PM, Eleftherios Garyfallidis wrote:

Great post Kostas. It does help a lot indeed. Storm looks very interesting :-) 

Alex?

On Wed, Feb 15, 2012 at 11:25 AM, Zoumpatianos Konstantinos <zoumpa...@disi.unitn.it> wrote:

Hello guys! 

I have used both the web frameworks for big applications. To my experience Django is by far better and less "restricting" and I would personally go for that choice if I had to choose between the two. 

But bare in mind that all of them are huge web app frameworks, and as such they do a lot of magic, which most of the times is really resource consuming for a big production environment, I'd go for Django just because most of its magic is restricted in its extremely good admin section, this means that it doesn't get in your way if you don't need it. 

If you have a really complex database model then both of them can make your life so much easier (Rails is doing more magic here).

But why not simply use a barebones ORM framework like storm (https://storm.canonical.com/), a simple templating language, an MVC pattern and a really simple web framework without any mambo jumbo for this?

Key differences:

• Django allows for developer-defined object relational mapping
• Rails also does that, but with a little more automation (which is not always optimal).

• Django has a custom templating language, that does not allow any python code to be run inside the views, one has to write custom tags that are parsed and executed by the templating language (I like that as it takes the ability out of the designers to do anything weird…)

• Rails supports .erb files which are embedded in ruby (ALTHOUGH you can use templating languages such as HAML which is not bad at all, just a bit exotic)

•  As far as extendability, I will have to say that there are more libraries available for rails, although this will not be a problem for the average web app, you can always do a gem install google_places and have a wonderful Google places API in your app.

To me rails is faster to get you going (for a prototype) but harder to maintain and build a scalable system on it, django is good enough to get you started + scale. But in any case if the complexity of an application lies beyond what is a "simple/standard" website then maybe a custom solution is better.

One company that I know use rails for the frontend but for every kind of serious jobs they have a web services architecture running on twisted/python.

But always key questions are what do other people with similar apps use. How complex is the application, what tools are available and in which language/framework. etc.

i hope this helps a bit,

Cheers,

Kostas 

On Wed, Feb 15, 2012 at 10:38 AM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

Thanx Eleftherios -

Rails is a Ruby WebSite/Apps-Components Lib and Django is a Python WebSite/Apps-Components Lib.

So I guess it is a mater of Python or Ruby, while PHP is the most popular yet by far. However, PHP it seem to have Great Limitations in the matter of Server Side Resource Efficiency but there are at least 100 engines and CMSs working on PHP.

I guess its a matter of choice whoever I think PHP is on its Sunset while Python and Ruby is on their Sunrise. As for Python vs Ruby in my web-based-research it seems " Ruby on Rail " to be very Fast for web development and " Python with Django " very Simple/Pure/Not-One-Line-Code-Does-it-ALL (in my opinion more versatile in the matter of maintenance for long term projects).

To conclude I think if one want to have an out-of-the-box solution the she/he should follow the PHP/CMS way. If not the its a matter of Flavor Preference.

Cheers!

Dimitrios

On 02/15/2012 03:02 AM, Eleftherios Garyfallidis wrote:

This is an interesting discussion between Django and Rails. I think it worth reading. 

http://www.quora.com/Which-should-I-learn-Django-or-Rails

:-)

[Eleftherios Garyfallidis]

Hi Kostas,

and thank you for you detailed response. As we are building an application which is targeting to an "unlimited" number of users we need to employ automated testing in all different languages. Do you think that this is reasonable with many languages being involved?

Cheers,

E.

[Dimitrios Pritsos]

On 02/15/2012 07:11 PM, Eleftherios Garyfallidis wrote:

Hi Kostas,

and thank you for you detailed response.�As we are building an application which is targeting to an "unlimited" number of users we need to employ automated testing in all different languages. Do you think that this is reasonable with many languages being involved?

Check out his last e-mail

Cheers,

E.

On Wed, Feb 15, 2012 at 4:32 PM, Zoumpatianos Konstantinos <zoumpa...@disi.unitn.it> wrote:

My personal approach is always to distribute. No need to stick to one language, one platform, one technology. You can build different parts of the system in different languages and stick them together. E.g. a web services based architecture.

The more independent each module is and the more clearly (and technology independent) its interface is defined then the best it is. I still haven't worked for a project where a module didn't change or even got re-written from scratch.�

I think the first part is to break down the system into modules. Identify the requirements for each module and their interconnections and then see what is appropriate, also taking into consideration the current knowledge of the team/resources + time.

Key questions:

- What are the backend requirements also considering the long term targets?

- What is the data model, how complex is it? Does it have a rich schema or not (nosql or sql and where)?

- How complex the user interface should be, how should it interact with the backend?

- Is the backend complex enough or is it simple enough and can be tightly coupled with the front-end?

- Is there a need of multiple backends collaborating with each other�

- Which modules could have performance issues?

On Wed, Feb 15, 2012 at 5:02 PM, Zoumpatianos Konstantinos <zoumpa...@disi.unitn.it> wrote:

NodeJS sounds really promising and there is a lot of buzz around it recently. Apparently there is also a good codebase for that:�https://github.com/joyent/node/wiki/modules.

If this is going to be a distributes collaborative system then real time communication between node<->node and node<->browser in a publish subscribe or similar fashion is crucial. A project that is also very promising and worths to take a look at:�http://www.ape-project.org/.

I am sure though that you can write comet services with nodejs too.

NodeJS is extendable via JS or C++ which is cool.

K.

On Wed, Feb 15, 2012 at 4:30 PM, Alexandros <atria...@gmail.com> wrote:

I have no problem with doing it in Django, or Ruby, the problem is that I have no experience on those and it will take some time to learn (however I always love learning new technologies :D )

on the other hand I'd like us to check out node.js a bit (where javascript is used throught the client side and the server side) , the one our "technical mentor" suggested over at the Startup Weekend. It seems quite promising...

Concerning the P2P. I would also like your suggestions guys. If we are to build this social tool with �the prospects of having a big social impact, especially if we go the non-profit way, we might want to go with a decentralized architecture (we can either do it the Diaspora way, or in more traditional P2P ways), one that would ensure user privacy and service independence�

What are your thoughts on that?

On Wed, Feb 15, 2012 at 3:30 PM, Eleftherios Garyfallidis <garyfa...@gmail.com> wrote:

Lets not decide immediately. I was talking with Alex yesterday on the phone. I think he will have some good suggestions too - even the possibility to build this peer-to-peer. He is most experienced than all of us so he should lead the design in the beginning and then we can start contribute. But yeah Django seems better than I was expecting - but do all servers (Apache) support it?

On Wed, Feb 15, 2012 at 1:24 PM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

It seems the Stuff I ve read so far plus some review to the Django book recently I ve acquired agrees to Kostas Experience. (Thanx Kostas)

YES, MVC it should be there in any Architect we might use.

There is a problem going from scratch if you want to go fast, eventhought some times for example for Ajax stuff is better to do it with basic custom libs instead of JQuerry or other Ajax lib. But in our case I think that there are lots of staff required as prerequisite to go from scratch. �

So Lets go Django. I will do that anyway for transferring my Web Site from PHP-Joomla/Virtuemart/+1k-of-Hacks to Django/Satchmo-Python. So I can work for both and gain experience faster.

((( There is Satchmo Project on Django Engine for E-Commenrce in case you do interested Kostas, it just an extension of Django and not a fork i.e. it goes better as Django goes better giving the basics to build an ecommerce fast!� - http://www.satchmoproject.com/ )))

Twisted is a lib mainly for building fast a Network App with Threading/Multiprocessing stuff built-in.

Cheers to all!

On 02/15/2012 01:46 PM, Eleftherios Garyfallidis wrote:

Great post Kostas. It does help a lot indeed. Storm looks very interesting :-)�

Alex?

On Wed, Feb 15, 2012 at 11:25 AM, Zoumpatianos Konstantinos <zoumpa...@disi.unitn.it> wrote:

Hello guys!�

I have used both the web frameworks for big applications. To my experience Django is by far better and less "restricting" and I would personally go for that choice if I had to choose between the two.�

But bare in mind that all of them are huge web app frameworks, and as such they do a lot of magic, which most of the times is really resource consuming for a big production environment, I'd go for Django just because most of its magic is restricted in its extremely good admin section, this means that it doesn't get in your way if you don't need it.�

If you have a really complex database model then both of them can make your life so much easier (Rails is doing more magic here).

But why not simply use a barebones ORM framework like storm (https://storm.canonical.com/), a simple templating language, an MVC pattern and a really simple web framework without any mambo jumbo for this?

Key differences:

• Django allows for developer-defined object relational mapping
• Rails also does that, but with a little more automation (which is not always optimal).

• Django has a custom templating language, that does not allow any python code to be run inside the views, one has to write custom tags that are parsed and executed by the templating language (I like that as it takes the ability out of the designers to do anything weird�)

• Rails supports .erb files which are embedded in ruby (ALTHOUGH you can use templating languages such as HAML which is not bad at all, just a bit exotic)

• �As far as extendability, I will have to say that there are more libraries available for rails, although this will not be a problem for the average web app, you can always do a gem install google_places and have a wonderful Google places API in your app.

To me rails is faster to get you going (for a prototype) but harder to maintain and build a scalable system on it, django is good enough to get you started + scale. But in any case if the complexity of an application lies beyond what is a "simple/standard" website then maybe a custom solution is better.

One company that I know use rails for the frontend but for every kind of serious jobs they have a web services architecture running on twisted/python.

But always key questions are what do other people with similar apps use. How complex is the application, what tools are available and in which language/framework. etc.

i hope this helps a bit,

Cheers,

Kostas�

�

On Wed, Feb 15, 2012 at 10:38 AM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

Thanx Eleftherios -

Rails is a Ruby WebSite/Apps-Components Lib and Django is a Python WebSite/Apps-Components Lib.

So I guess it is a mater of Python or Ruby, while PHP is the most popular yet by far. However, PHP it seem to have Great Limitations in the matter of Server Side Resource Efficiency but there are at least 100 engines and CMSs working on PHP.

I guess its a matter of choice whoever I think PHP is on its Sunset while Python and Ruby is on their Sunrise. As for Python vs Ruby in my web-based-research it seems " Ruby on Rail " to be very Fast for web development and " Python with Django " very Simple/Pure/Not-One-Line-Code-Does-it-ALL (in my opinion more versatile in the matter of maintenance for long term projects).

To conclude I think if one want to have an out-of-the-box solution the she/he should follow the PHP/CMS way. If not the its a matter of Flavor Preference.

Cheers!

Dimitrios

On 02/15/2012 03:02 AM, Eleftherios Garyfallidis wrote:

This is an interesting discussion between Django and Rails. I think it worth reading.�

http://www.quora.com/Which-should-I-learn-Django-or-Rails

:-)

[Eleftherios Garyfallidis]

I saw it Dimitris but I see nothing about tests. Am I missing something?

On Wed, Feb 15, 2012 at 5:14 PM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

On 02/15/2012 07:11 PM, Eleftherios Garyfallidis wrote:

Hi Kostas,

and thank you for you detailed response. As we are building an application which is targeting to an "unlimited" number of users we need to employ automated testing in all different languages. Do you think that this is reasonable with many languages being involved?

Check out his last e-mail

Cheers,

E.

On Wed, Feb 15, 2012 at 4:32 PM, Zoumpatianos Konstantinos <zoumpa...@disi.unitn.it> wrote:

My personal approach is always to distribute. No need to stick to one language, one platform, one technology. You can build different parts of the system in different languages and stick them together. E.g. a web services based architecture.

The more independent each module is and the more clearly (and technology independent) its interface is defined then the best it is. I still haven't worked for a project where a module didn't change or even got re-written from scratch. 

I think the first part is to break down the system into modules. Identify the requirements for each module and their interconnections and then see what is appropriate, also taking into consideration the current knowledge of the team/resources + time.

Key questions:

- What are the backend requirements also considering the long term targets?

- What is the data model, how complex is it? Does it have a rich schema or not (nosql or sql and where)?

- How complex the user interface should be, how should it interact with the backend?

- Is the backend complex enough or is it simple enough and can be tightly coupled with the front-end?

- Is there a need of multiple backends collaborating with each other 

- Which modules could have performance issues?

On Wed, Feb 15, 2012 at 5:02 PM, Zoumpatianos Konstantinos <zoumpa...@disi.unitn.it> wrote:

NodeJS sounds really promising and there is a lot of buzz around it recently. Apparently there is also a good codebase for that: https://github.com/joyent/node/wiki/modules.

If this is going to be a distributes collaborative system then real time communication between node<->node and node<->browser in a publish subscribe or similar fashion is crucial. A project that is also very promising and worths to take a look at: http://www.ape-project.org/.

I am sure though that you can write comet services with nodejs too.

NodeJS is extendable via JS or C++ which is cool.

K.

On Wed, Feb 15, 2012 at 4:30 PM, Alexandros <atria...@gmail.com> wrote:

I have no problem with doing it in Django, or Ruby, the problem is that I have no experience on those and it will take some time to learn (however I always love learning new technologies :D )

on the other hand I'd like us to check out node.js a bit (where javascript is used throught the client side and the server side) , the one our "technical mentor" suggested over at the Startup Weekend. It seems quite promising...

Concerning the P2P. I would also like your suggestions guys. If we are to build this social tool with  the prospects of having a big social impact, especially if we go the non-profit way, we might want to go with a decentralized architecture (we can either do it the Diaspora way, or in more traditional P2P ways), one that would ensure user privacy and service independence 

What are your thoughts on that?

On Wed, Feb 15, 2012 at 3:30 PM, Eleftherios Garyfallidis <garyfa...@gmail.com> wrote:

Lets not decide immediately. I was talking with Alex yesterday on the phone. I think he will have some good suggestions too - even the possibility to build this peer-to-peer. He is most experienced than all of us so he should lead the design in the beginning and then we can start contribute. But yeah Django seems better than I was expecting - but do all servers (Apache) support it?

On Wed, Feb 15, 2012 at 1:24 PM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

It seems the Stuff I ve read so far plus some review to the Django book recently I ve acquired agrees to Kostas Experience. (Thanx Kostas)

YES, MVC it should be there in any Architect we might use.

There is a problem going from scratch if you want to go fast, eventhought some times for example for Ajax stuff is better to do it with basic custom libs instead of JQuerry or other Ajax lib. But in our case I think that there are lots of staff required as prerequisite to go from scratch.  

So Lets go Django. I will do that anyway for transferring my Web Site from PHP-Joomla/Virtuemart/+1k-of-Hacks to Django/Satchmo-Python. So I can work for both and gain experience faster.

((( There is Satchmo Project on Django Engine for E-Commenrce in case you do interested Kostas, it just an extension of Django and not a fork i.e. it goes better as Django goes better giving the basics to build an ecommerce fast!  - http://www.satchmoproject.com/ )))

Twisted is a lib mainly for building fast a Network App with Threading/Multiprocessing stuff built-in.

Cheers to all!

On 02/15/2012 01:46 PM, Eleftherios Garyfallidis wrote:

Great post Kostas. It does help a lot indeed. Storm looks very interesting :-) 

Alex?

On Wed, Feb 15, 2012 at 11:25 AM, Zoumpatianos Konstantinos <zoumpa...@disi.unitn.it> wrote:

Hello guys! 

I have used both the web frameworks for big applications. To my experience Django is by far better and less "restricting" and I would personally go for that choice if I had to choose between the two. 

But bare in mind that all of them are huge web app frameworks, and as such they do a lot of magic, which most of the times is really resource consuming for a big production environment, I'd go for Django just because most of its magic is restricted in its extremely good admin section, this means that it doesn't get in your way if you don't need it. 

If you have a really complex database model then both of them can make your life so much easier (Rails is doing more magic here).

But why not simply use a barebones ORM framework like storm (https://storm.canonical.com/), a simple templating language, an MVC pattern and a really simple web framework without any mambo jumbo for this?

Key differences:

• Django allows for developer-defined object relational mapping
• Rails also does that, but with a little more automation (which is not always optimal).

• Django has a custom templating language, that does not allow any python code to be run inside the views, one has to write custom tags that are parsed and executed by the templating language (I like that as it takes the ability out of the designers to do anything weird…)

• Rails supports .erb files which are embedded in ruby (ALTHOUGH you can use templating languages such as HAML which is not bad at all, just a bit exotic)

•  As far as extendability, I will have to say that there are more libraries available for rails, although this will not be a problem for the average web app, you can always do a gem install google_places and have a wonderful Google places API in your app.

To me rails is faster to get you going (for a prototype) but harder to maintain and build a scalable system on it, django is good enough to get you started + scale. But in any case if the complexity of an application lies beyond what is a "simple/standard" website then maybe a custom solution is better.

One company that I know use rails for the frontend but for every kind of serious jobs they have a web services architecture running on twisted/python.

But always key questions are what do other people with similar apps use. How complex is the application, what tools are available and in which language/framework. etc.

i hope this helps a bit,

Cheers,

Kostas 

On Wed, Feb 15, 2012 at 10:38 AM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

Thanx Eleftherios -

Rails is a Ruby WebSite/Apps-Components Lib and Django is a Python WebSite/Apps-Components Lib.

So I guess it is a mater of Python or Ruby, while PHP is the most popular yet by far. However, PHP it seem to have Great Limitations in the matter of Server Side Resource Efficiency but there are at least 100 engines and CMSs working on PHP.

I guess its a matter of choice whoever I think PHP is on its Sunset while Python and Ruby is on their Sunrise. As for Python vs Ruby in my web-based-research it seems " Ruby on Rail " to be very Fast for web development and " Python with Django " very Simple/Pure/Not-One-Line-Code-Does-it-ALL (in my opinion more versatile in the matter of maintenance for long term projects).

To conclude I think if one want to have an out-of-the-box solution the she/he should follow the PHP/CMS way. If not the its a matter of Flavor Preference.

Cheers!

Dimitrios

On 02/15/2012 03:02 AM, Eleftherios Garyfallidis wrote:

This is an interesting discussion between Django and Rails. I think it worth reading. 

http://www.quora.com/Which-should-I-learn-Django-or-Rails

:-)

[Zoumpatianos Konstantinos]

It could be a problem I agree you are right, but I would like the idea of having a standalone service like a server which can do all the hard work and a separate front-end. 

So for example you can easily create a Python/C++ server which runs on each node. Which is also easy to test and install and lets the users use a variety of front-ends. 

The important part is not to use different languages per se, but having the ability to do so. 

One can build everything on python but create modules communicating with each other via open apis so that if a third party or you can provide a better implementation it will still be possible (leaving space for scaling cpu intensive stuff). 

About tests, if the number of languages is reasonable and well integrated then each subsystem can have its own tests. But maybe I am missing something here so please let me know if I am wrong.

[Eleftherios Garyfallidis]

Oh yes I see your point and completely agree. :-)

[Dimitrios Pritsos]

I would suggest to follow a Centralized WebApp implementation and then we can expand the model be on Distributed Nodes. In addition, for the CORE Voting engine of the Project I cannot see the usefulness of such an approach to start with. In case you are referring to a Cloud-Hosted WebApp where the Cloud is a Grid of Distributed Nodes this is an other story and still no need to be the starting point.

Cheers to all,

Mitsos

On 02/15/2012 07:26 PM, Eleftherios Garyfallidis wrote:

Oh yes I see your point and completely agree. :-)

On Wed, Feb 15, 2012 at 5:25 PM, Zoumpatianos Konstantinos <zoumpa...@disi.unitn.it> wrote:

It could be a problem I agree you are right, but I would like the idea of having a standalone service like a server which can do all the hard work and a separate front-end.�

So for example you can easily create a Python/C++ server which runs on each node. Which is also easy to test and install and lets the users use a variety of front-ends.�

The important part is not to use different languages per se, but having the ability to do so.�

One can build everything on python but create modules communicating with each other via open apis so that if a third party or you can provide a better implementation it will still be possible (leaving space for scaling cpu intensive stuff).�

About tests, if the number of languages is reasonable and well integrated then each subsystem can have its own tests. But maybe I am missing something here so please let me know if I am wrong.

On Wed, Feb 15, 2012 at 6:11 PM, Eleftherios Garyfallidis <garyfa...@gmail.com> wrote:

Hi Kostas,

and thank you for you detailed response.�As we are building an application which is targeting to an "unlimited" number of users we need to employ automated testing in all different languages. Do you think that this is reasonable with many languages being involved?

Cheers,

E.

On Wed, Feb 15, 2012 at 4:32 PM, Zoumpatianos Konstantinos <zoumpa...@disi.unitn.it> wrote:

My personal approach is always to distribute. No need to stick to one language, one platform, one technology. You can build different parts of the system in different languages and stick them together. E.g. a web services based architecture.

The more independent each module is and the more clearly (and technology independent) its interface is defined then the best it is. I still haven't worked for a project where a module didn't change or even got re-written from scratch.�

I think the first part is to break down the system into modules. Identify the requirements for each module and their interconnections and then see what is appropriate, also taking into consideration the current knowledge of the team/resources + time.

Key questions:

- What are the backend requirements also considering the long term targets?

- What is the data model, how complex is it? Does it have a rich schema or not (nosql or sql and where)?

- How complex the user interface should be, how should it interact with the backend?

- Is the backend complex enough or is it simple enough and can be tightly coupled with the front-end?

- Is there a need of multiple backends collaborating with each other�

- Which modules could have performance issues?

On Wed, Feb 15, 2012 at 5:02 PM, Zoumpatianos Konstantinos <zoumpa...@disi.unitn.it> wrote:

NodeJS sounds really promising and there is a lot of buzz around it recently. Apparently there is also a good codebase for that:�https://github.com/joyent/node/wiki/modules.

If this is going to be a distributes collaborative system then real time communication between node<->node and node<->browser in a publish subscribe or similar fashion is crucial. A project that is also very promising and worths to take a look at:�http://www.ape-project.org/.

I am sure though that you can write comet services with nodejs too.

NodeJS is extendable via JS or C++ which is cool.

K.

On Wed, Feb 15, 2012 at 4:30 PM, Alexandros <atria...@gmail.com> wrote:

I have no problem with doing it in Django, or Ruby, the problem is that I have no experience on those and it will take some time to learn (however I always love learning new technologies :D )

on the other hand I'd like us to check out node.js a bit (where javascript is used throught the client side and the server side) , the one our "technical mentor" suggested over at the Startup Weekend. It seems quite promising...

Concerning the P2P. I would also like your suggestions guys. If we are to build this social tool with �the prospects of having a big social impact, especially if we go the non-profit way, we might want to go with a decentralized architecture (we can either do it the Diaspora way, or in more traditional P2P ways), one that would ensure user privacy and service independence�

What are your thoughts on that?

On Wed, Feb 15, 2012 at 3:30 PM, Eleftherios Garyfallidis <garyfa...@gmail.com> wrote:

Lets not decide immediately. I was talking with Alex yesterday on the phone. I think he will have some good suggestions too - even the possibility to build this peer-to-peer. He is most experienced than all of us so he should lead the design in the beginning and then we can start contribute. But yeah Django seems better than I was expecting - but do all servers (Apache) support it?

On Wed, Feb 15, 2012 at 1:24 PM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

It seems the Stuff I ve read so far plus some review to the Django book recently I ve acquired agrees to Kostas Experience. (Thanx Kostas)

YES, MVC it should be there in any Architect we might use.

There is a problem going from scratch if you want to go fast, eventhought some times for example for Ajax stuff is better to do it with basic custom libs instead of JQuerry or other Ajax lib. But in our case I think that there are lots of staff required as prerequisite to go from scratch. �

So Lets go Django. I will do that anyway for transferring my Web Site from PHP-Joomla/Virtuemart/+1k-of-Hacks to Django/Satchmo-Python. So I can work for both and gain experience faster.

((( There is Satchmo Project on Django Engine for E-Commenrce in case you do interested Kostas, it just an extension of Django and not a fork i.e. it goes better as Django goes better giving the basics to build an ecommerce fast!� - http://www.satchmoproject.com/ )))

Twisted is a lib mainly for building fast a Network App with Threading/Multiprocessing stuff built-in.

Cheers to all!

On 02/15/2012 01:46 PM, Eleftherios Garyfallidis wrote:

Great post Kostas. It does help a lot indeed. Storm looks very interesting :-)�

Alex?

On Wed, Feb 15, 2012 at 11:25 AM, Zoumpatianos Konstantinos <zoumpa...@disi.unitn.it> wrote:

Hello guys!�

I have used both the web frameworks for big applications. To my experience Django is by far better and less "restricting" and I would personally go for that choice if I had to choose between the two.�

But bare in mind that all of them are huge web app frameworks, and as such they do a lot of magic, which most of the times is really resource consuming for a big production environment, I'd go for Django just because most of its magic is restricted in its extremely good admin section, this means that it doesn't get in your way if you don't need it.�

If you have a really complex database model then both of them can make your life so much easier (Rails is doing more magic here).

But why not simply use a barebones ORM framework like storm (https://storm.canonical.com/), a simple templating language, an MVC pattern and a really simple web framework without any mambo jumbo for this?

Key differences:

• Django allows for developer-defined object relational mapping
• Rails also does that, but with a little more automation (which is not always optimal).

• Django has a custom templating language, that does not allow any python code to be run inside the views, one has to write custom tags that are parsed and executed by the templating language (I like that as it takes the ability out of the designers to do anything weird�)

• Rails supports .erb files which are embedded in ruby (ALTHOUGH you can use templating languages such as HAML which is not bad at all, just a bit exotic)

• �As far as extendability, I will have to say that there are more libraries available for rails, although this will not be a problem for the average web app, you can always do a gem install google_places and have a wonderful Google places API in your app.

To me rails is faster to get you going (for a prototype) but harder to maintain and build a scalable system on it, django is good enough to get you started + scale. But in any case if the complexity of an application lies beyond what is a "simple/standard" website then maybe a custom solution is better.

One company that I know use rails for the frontend but for every kind of serious jobs they have a web services architecture running on twisted/python.

But always key questions are what do other people with similar apps use. How complex is the application, what tools are available and in which language/framework. etc.

i hope this helps a bit,

Cheers,

Kostas�

�

On Wed, Feb 15, 2012 at 10:38 AM, Dimitrios Pritsos <dpri...@extremepro.gr> wrote:

Thanx Eleftherios -

Rails is a Ruby WebSite/Apps-Components Lib and Django is a Python WebSite/Apps-Components Lib.

So I guess it is a mater of Python or Ruby, while PHP is the most popular yet by far. However, PHP it seem to have Great Limitations in the matter of Server Side Resource Efficiency but there are at least 100 engines and CMSs working on PHP.

I guess its a matter of choice whoever I think PHP is on its Sunset while Python and Ruby is on their Sunrise. As for Python vs Ruby in my web-based-research it seems " Ruby on Rail " to be very Fast for web development and " Python with Django " very Simple/Pure/Not-One-Line-Code-Does-it-ALL (in my opinion more versatile in the matter of maintenance for long term projects).

To conclude I think if one want to have an out-of-the-box solution the she/he should follow the PHP/CMS way. If not the its a matter of Flavor Preference.

Cheers!

Dimitrios

On 02/15/2012 03:02 AM, Eleftherios Garyfallidis wrote:

This is an interesting discussion between Django and Rails. I think it worth reading.�

http://www.quora.com/Which-should-I-learn-Django-or-Rails

:-)

[Phoebus G]

Blast from the past - but.
I like the modules approach due to the immensity of the project once it gains speed.

Also due to the many different functions and level of security each requires to operate as required.

I think the Django decision is obvious especially if extending with C++ is possible. And given all I've read and tested so far on Python. 

For the modules that deal with voting we need a lot of low-level code. A peer-to-peer system in itself with tight secure coding, that once it starts operating it becomes a closed system with high encryption, security and verifiability. (As an idea, in case the name/site bitvote.net does not work, this side-project could focus solely on this portion).

The same goes for the identification/auth modules: At first   2-way authentication and then authentication based on bioinformatics. Biggest question is how to initiate a user in a closed system. Preventing fraudulent account, double account (that lead to double-voting). I am working on some designs that will allow any pre-authorized member to with bioidentification for anyone belonging to the human class (aliens will need their own chain...). 2-way auth for our start phase/testing while we dev other areas is ok. But users will have to trust us, and we'll have to trust ourselves (but what about our common disease of amnesia by confabulation?). Alright, neuropsych-joke here :)

Information pooling & GUI higher level. I am thinking of a responsive GUI that helps the user right then and there check sources and facts while typing a proposal. Formating the text for easy reading (by humans and machines). 

Module for text evaluation for (originality, complexity) - similar modules with the realtime feedback at composition but deeper checks with the existing DB. 

Datastores for the common datatypes/objects. Centralized, 'hijacked', peer-to-peer. If a proposal makes it to the list from which voters will choose, then it becomes important and its integrity will need to be verified. So, we copy it to the peer-to-peer datastore and it becomes a part of the 'chain', a - public record ready for verification by anyone running the software. (Questions of max optimization, storage, encryption -> depends on ID/auth). Hijacked: public information and APIs - stability issue, how do we deal with no longer accessible sources? Maintenance team comprised of volunteers headed by our staff?. This though is important because it gives our application data depth as wide as the internet without having to handle it and store it internally. (Lots of fun questions are begged and opened here I know, isn't it cool?). Centralized: things we keep on hosted server(s) but may be in an open format - statistics, administrative uses. 

Are there peer-to-peer databases to look at and gain insight from? Alex has made mention of this possibility, and to me it's an ethical requirement (but also bodes well with the public's paranoia about e-voting). 

Overall questions, making the app optimized so it can run on low end systems - but not a huge priority at first obviously. 

There are a lot of advances in the bio-id department that (sadly) most of which are being kept behind closed doors. Estonia's e-gov is based on their digital ID. But if we want to make a system that's beyond local govs, we've to necessarily focus on bio-id - or trust one of the companies focusing on that to do it for us? But do you?

That's all for now... hoping many of you will have found windows of time and excitement to put the project back on track :)