So I have been actively working with drupal for the past several months, trying to get it up and running for an NGO in India. The experience has been fairly smooth and I have even gotten the hang of developing and extending modules for the system. Just a couple of weeks ago following some self-assessment on working with drupal I began considering it as framework for developing a pattern based knowledge management system.
That was of course until two interesting conversations took place. The first conversation was with Yishay who pointed me to the Google Appengine project. He already knew I was a fan of python and django so he brought this up as an alternative to working with drupal.
In all honesty (as I have said in previous posts) I would rather develop with a language like python and framework such as django. Now with the added integration with Appengine it seemed as a an interesting direction to take.
Strangely, the next day at work I was given the green light to begin diving head first into this django/appengine phenomena. We have been actively using SharePoint for most of our projects. Whereas myself I have bucked the system from the get go, instead opting to use google apps and/or building my own as needed.
Well, it seems that my efforts did not go unrecognized and with the help of a few collegues it seems that the google route was partially embraced even if it was just from the standpoint of conducting an investigation of what we might be able to do.
Personally, I would love to develop solely with django and python at work, and well it looks like I get my wish. So for this summer I get to spend all of my time getting acquainted with appengine and see what it can do. Where does this leave me with drupal and my knowledge management system? Well, it leaves with wrapping up my current project for JESA and most likely focusing on using the django framework as the foundation for developing the components needed for my system.
I feel like I have been on a merry-go-round, but considering the options, this summer's work and fellow colleagues giving me the space to become relatively proficient with this system it seems like a given that I will try and use this framework to produce my software.
I'm actually pretty excited about the prospect, as it seems like I'm in a perfect position to take advantage of the django/appengine integration. I'm a huge python fan and it is the language I'm most proficient with. I know django, having built a couple of blog and wiki apps (one day I will move this blog to the one I built), and well appengine uses BigTable and that looks to be an interesting adventure. So taking that together with what I want to do with the application I'm building it seems like a great tool set.
So, thanks Yishay, thanks Gary and definitely thanks to Jamie and Theron for pushing a multi-paradigm software shop at CTLT.
Showing posts with label Django. Show all posts
Showing posts with label Django. Show all posts
Sunday, April 20, 2008
Sunday, November 4, 2007
Evaluating Technologies for CI Research Project
As you might all know I'm particularly fascinated with 3 core open source projects at the moment. These of course being Plone, Drupal and Django. Plone and Drupal are interesting CMS applications which attempt to be usable systems for developing much more complex and customized software solutions. On the other hand, Django is a rapid development framework that could allow for the development of a Plone or Drupal type application. I think all have a very useful place, particularly within the non-profit software development field.
I have issues with each though and in some sense these issues might be ridiculous, but they are my reasons and I have never been accused of being practical.
The first issue though is practical and that is the hosting cost associated with Plone. Though Plone might be the most feature rich platform (not to mention I know it the best), with its stable integration of GIS through the web apps, it is cost prohibitive for most of the groups I'm currently working with. This is very annoying, but that is life.
The issue I have with Drupal is its use of PHP and its non-object oriented approach to using PHP. Yes, for some this is a stupid reason not to adopt a particular solution. After all, I predominately work with PHP. Not to mention, Drupal is full featured and growing rapidly as more users adopt and build custom modules, extending its capabilities. It is also a cheap solution.
Yet, I like Python, its cleanliness, readability and development speed. As a result, Django provides a very enticing opportunity, to build robust apps with Python. Django is also cheap to host. However, despite the useful helpers such as the Django admin, nice permission system and so on, it lacks a lot of the components already available to Drupal and Plone developers. This means that I would have to implement the various components myself or find like minded people interested in collaborating to reduce development time.
Yet, despite this very obvious problem, I find the lack of a django based application to fit my needs to be very irritating as this is perhaps the most powerful Python web framework I have come across (save for Pylons, but crappy documentation makes for crappy adoption). This almost seems to be a calling of sorts. There needs to be a powerful django app similar to drupal for us pythonistas. Yes, there is PyLucid, but the documentation is not very good and the level of deviation from the core django framework just seems unnecessary to me. There is already so much Django offers that it just seems to be a waste of time.
Now, I haven't completely sold myself on using Django, but I'm using it to write a custom shell of a CMS for JESA, currently the site I built is just static HTML, but as the requirements for this site expand dramatically (as I thought they would) they are in desperate need of an easy to use web app that allows them to extend the site and add content with ease.
This is all volunteer work, but there are some things to be said about doing volunteer work versus contract work. I have been given free reign to build the site and to use whatever technology I want provided the site is secure, easy to use, etc.
So a great opportunity to use django. I think after this I will be better able to gauge whether I want to invest the time to build a base CMS for my research or if Drupal will just have to cut it. We'll see.
I have issues with each though and in some sense these issues might be ridiculous, but they are my reasons and I have never been accused of being practical.
The first issue though is practical and that is the hosting cost associated with Plone. Though Plone might be the most feature rich platform (not to mention I know it the best), with its stable integration of GIS through the web apps, it is cost prohibitive for most of the groups I'm currently working with. This is very annoying, but that is life.
The issue I have with Drupal is its use of PHP and its non-object oriented approach to using PHP. Yes, for some this is a stupid reason not to adopt a particular solution. After all, I predominately work with PHP. Not to mention, Drupal is full featured and growing rapidly as more users adopt and build custom modules, extending its capabilities. It is also a cheap solution.
Yet, I like Python, its cleanliness, readability and development speed. As a result, Django provides a very enticing opportunity, to build robust apps with Python. Django is also cheap to host. However, despite the useful helpers such as the Django admin, nice permission system and so on, it lacks a lot of the components already available to Drupal and Plone developers. This means that I would have to implement the various components myself or find like minded people interested in collaborating to reduce development time.
Yet, despite this very obvious problem, I find the lack of a django based application to fit my needs to be very irritating as this is perhaps the most powerful Python web framework I have come across (save for Pylons, but crappy documentation makes for crappy adoption). This almost seems to be a calling of sorts. There needs to be a powerful django app similar to drupal for us pythonistas. Yes, there is PyLucid, but the documentation is not very good and the level of deviation from the core django framework just seems unnecessary to me. There is already so much Django offers that it just seems to be a waste of time.
Now, I haven't completely sold myself on using Django, but I'm using it to write a custom shell of a CMS for JESA, currently the site I built is just static HTML, but as the requirements for this site expand dramatically (as I thought they would) they are in desperate need of an easy to use web app that allows them to extend the site and add content with ease.
This is all volunteer work, but there are some things to be said about doing volunteer work versus contract work. I have been given free reign to build the site and to use whatever technology I want provided the site is secure, easy to use, etc.
So a great opportunity to use django. I think after this I will be better able to gauge whether I want to invest the time to build a base CMS for my research or if Drupal will just have to cut it. We'll see.
Wednesday, October 17, 2007
To do List:
Feeling a bit overwhelmed so I figured I put up a to-do list:
Immediate -
1. Finish ICLS proposal (Today!)
2. Revise Original proposal between the Public Sphere, CTLT and the LKL
3. Finish Stats Exam - Do the research and run tests.
4. Write Paper #2 on Duwamish River Clean-up.
5. Keep Working on inserting content for Decon-Hotz
Next:
6. Keep Working on ePortfolio.
7. Create Subsite for Interactive Class Project (Technology for Conflict Negotiation)
8. Finalize and upload content for JESA site.
9. Begin Designing CMS for JESA (Plone, Drupal or Django)
10. Fix the new Public Sphere Project home-page.
11. Write Proposal for "Designing for the 21st Century: Using Web 2.0 Technologies (and Social Networking Tools) for Social Action."
12. Get ready for "Visual Reasoning Work-Shop", my topic is visualizing patterns for problem-solving.
Ongoing:
13. Keep up with my Django education.
14. Continue Design Scheme for Plone-Based CMS written on top of Django.
15. Concept Mapping and Document Centered Chat app with Django/Ajax.
Ouch, this list actually makes it sound worse!
Immediate -
1. Finish ICLS proposal (Today!)
2. Revise Original proposal between the Public Sphere, CTLT and the LKL
3. Finish Stats Exam - Do the research and run tests.
4. Write Paper #2 on Duwamish River Clean-up.
5. Keep Working on inserting content for Decon-Hotz
Next:
6. Keep Working on ePortfolio.
7. Create Subsite for Interactive Class Project (Technology for Conflict Negotiation)
8. Finalize and upload content for JESA site.
9. Begin Designing CMS for JESA (Plone, Drupal or Django)
10. Fix the new Public Sphere Project home-page.
11. Write Proposal for "Designing for the 21st Century: Using Web 2.0 Technologies (and Social Networking Tools) for Social Action."
12. Get ready for "Visual Reasoning Work-Shop", my topic is visualizing patterns for problem-solving.
Ongoing:
13. Keep up with my Django education.
14. Continue Design Scheme for Plone-Based CMS written on top of Django.
15. Concept Mapping and Document Centered Chat app with Django/Ajax.
Ouch, this list actually makes it sound worse!
Tuesday, October 16, 2007
GeoDjango for Environmental Informatics
So I found a very cool Django project called GeoDjango. It is a geo-spatial extension of the Django code project and seems to be a very promising application framework. I’m still very new to GIS, yet my interests and program of study is meant to incorporate some of the elements that this project seeks to address.
One of the things that I’m really interested in as a correlation to using L.V. patterns is the integration of simple geo-spatial data for community groups to collaboratively develop, extend and utilize in their work.
Along with the usage of this data is the ability to create maps to help in decision-making. However, next to the application of maps and collaborative mapping is the need to preserve community memory and the decisions that groups make to address community resource issues.
Along, with the potential to use Django as a framework for through the web GIS, I have been looking at applications such as EarthBrowser and Google Earth. Both seem promising additions. However, I was reading the EarthBrowser blog and he notes his interest in Django and I’m wondering what he is doing to enable through the web geo-spatial views. Plus, it seems at this point EarthBrowser is a much more rich application. Perhaps, this is due to its long development history. I guess in this sense I'm pretty agnostic. I just want whatever is cheapest, i.e. free and easiest to integrate into my web apps.
Anyway, with the ability to integrate these elements and along with the integration of a collaborative pattern language design module it is hoped that we can begin to provide not only the quantitatively appropriate data, but also a qualitatively appropriate approach to the design and usage of this data.
One of the things that I’m really interested in as a correlation to using L.V. patterns is the integration of simple geo-spatial data for community groups to collaboratively develop, extend and utilize in their work.
Along with the usage of this data is the ability to create maps to help in decision-making. However, next to the application of maps and collaborative mapping is the need to preserve community memory and the decisions that groups make to address community resource issues.
Along, with the potential to use Django as a framework for through the web GIS, I have been looking at applications such as EarthBrowser and Google Earth. Both seem promising additions. However, I was reading the EarthBrowser blog and he notes his interest in Django and I’m wondering what he is doing to enable through the web geo-spatial views. Plus, it seems at this point EarthBrowser is a much more rich application. Perhaps, this is due to its long development history. I guess in this sense I'm pretty agnostic. I just want whatever is cheapest, i.e. free and easiest to integrate into my web apps.
Anyway, with the ability to integrate these elements and along with the integration of a collaborative pattern language design module it is hoped that we can begin to provide not only the quantitatively appropriate data, but also a qualitatively appropriate approach to the design and usage of this data.
Sunday, October 14, 2007
Another CMS (Django Style)
Yes, I have been playing pretty extensively with Django these past few days and I love it. It is so intuitive for me. I don't think I have found a single approach to web app development that seems as easy as this.
Today, I was working with the default Admin provided and started thinking of ways to alter it and extend it. With Django, they give you the basic things needed, but no more no less. However, many of the pieces given appear to be easily altered and this could prove useful.
See, out of all the CMS apps out there, I like Plone the best. However, the hosting cost can be prohibitive for some groups, also I still don't like the way Skins are developed. I can do it, but for others it seems a bit steep. I'm interested in applications that are fairly easy to extend and customize. In this area Drupal seems to have it right on. However, with Drupal, the Admin is poorly developed and the way in which users interact with content is weird. I also, dislike the lack of structure. The Plone notion of organizing content in Folders just seems super easy versus Drupal's whatever, wherever approach.
Django, as a base framework provides a very simple templating system similar to Drupal, but Django is written in Python, object oriented and all (Yes, I know PHP is OO, but Drupal takes a more procedural approach). Django's admin is also clean and fairly intuitive; it does have some work, but I think I can integrate the Django admin in a more folderish and content/location specific way such as Plone does then we might have a really interesting extension of Django and skeletal app similar to Plone, but with the hosting cost more in line with Drupal.
For me writing an app in Django is much easier than writing a Product in Plone and yet, they function in the same way.
Django issues (these are things that need to get done to make Django more friendly for CMS development):
1. Easily defined URLs, power-users shouldn't have to write regular expressions. When installing an app a site manager should be able to easily set the urls associated with a particular piece of content with out getting into the code. This means users could also add pieces.
2. Users and Group Permissions, Plone does this very well and while Django has a powerful security system is seems pretty bare.
3. Folderish structure. When adding a module or app the piece should act as a folder and the pieces of content associated should be connected to it. For instance, I add a blog module; a base url is generated and anytime I add a blog content-type (e.g. a Post) then that content would live under the blog heading as a child of the blog. This way we could enforce a bit of structure. Of course some people might hate this, but for us Info Architects this structure would be nice.
4. Admin to be embedded. Currently the admin is a whole different piece of the site. The admin should only come up for adding content modules at the root of the site. Below the root, I would think that the admin should be referenced and any edits would be on the piece of content a user is currently viewing. This is also very well done in Plone.
5. In my module app I need to write a piece of code that will allow me to update the urlpatterns(). Unfortunately, the urlpatterns variable is a damn tuple. A list would make life a bit easier.
Anyway, these are some of the things I'm thinking of addressing. If I can work with some haste I might be able to have the first cut before the next semester and maybe we can deploy for the new JESA site. I think I will deploy for my own site first though. Need to watch out for those XSS attacks. I'd rather my stuff crash than theirs.
Today, I was working with the default Admin provided and started thinking of ways to alter it and extend it. With Django, they give you the basic things needed, but no more no less. However, many of the pieces given appear to be easily altered and this could prove useful.
See, out of all the CMS apps out there, I like Plone the best. However, the hosting cost can be prohibitive for some groups, also I still don't like the way Skins are developed. I can do it, but for others it seems a bit steep. I'm interested in applications that are fairly easy to extend and customize. In this area Drupal seems to have it right on. However, with Drupal, the Admin is poorly developed and the way in which users interact with content is weird. I also, dislike the lack of structure. The Plone notion of organizing content in Folders just seems super easy versus Drupal's whatever, wherever approach.
Django, as a base framework provides a very simple templating system similar to Drupal, but Django is written in Python, object oriented and all (Yes, I know PHP is OO, but Drupal takes a more procedural approach). Django's admin is also clean and fairly intuitive; it does have some work, but I think I can integrate the Django admin in a more folderish and content/location specific way such as Plone does then we might have a really interesting extension of Django and skeletal app similar to Plone, but with the hosting cost more in line with Drupal.
For me writing an app in Django is much easier than writing a Product in Plone and yet, they function in the same way.
Django issues (these are things that need to get done to make Django more friendly for CMS development):
1. Easily defined URLs, power-users shouldn't have to write regular expressions. When installing an app a site manager should be able to easily set the urls associated with a particular piece of content with out getting into the code. This means users could also add pieces.
2. Users and Group Permissions, Plone does this very well and while Django has a powerful security system is seems pretty bare.
3. Folderish structure. When adding a module or app the piece should act as a folder and the pieces of content associated should be connected to it. For instance, I add a blog module; a base url is generated and anytime I add a blog content-type (e.g. a Post) then that content would live under the blog heading as a child of the blog. This way we could enforce a bit of structure. Of course some people might hate this, but for us Info Architects this structure would be nice.
4. Admin to be embedded. Currently the admin is a whole different piece of the site. The admin should only come up for adding content modules at the root of the site. Below the root, I would think that the admin should be referenced and any edits would be on the piece of content a user is currently viewing. This is also very well done in Plone.
5. In my module app I need to write a piece of code that will allow me to update the urlpatterns(). Unfortunately, the urlpatterns variable is a damn tuple. A list would make life a bit easier.
Anyway, these are some of the things I'm thinking of addressing. If I can work with some haste I might be able to have the first cut before the next semester and maybe we can deploy for the new JESA site. I think I will deploy for my own site first though. Need to watch out for those XSS attacks. I'd rather my stuff crash than theirs.
Sunday, October 7, 2007
Why Django is good for Python
So it is no secret that I love Plone the CMS, and I have been enjoying the past few days of getting into the Plone 3 way of doing things, which is really a Zope 3 way of doing things. However, Plone 3 is extremely complex, after all it is an enterprise level application with an enormous amount of flexibility and tools built into it such as the new KSS ajax framework. Plus, Zope itself is a gargantuan project. Plone uses Zope 2 + Zope 3 = Five. the mixing of the two Zope technologies are not very intuitive (IMHO). For instance, I'm still use to the Zope 2 approach to Plone, though I have played with Zope 3, which from a framework perspective is much better than Zope 2. But putting them together is making my brain hurt.
This steep learning curve, which feels now even steeper seems to make it hard to get new developers to utilize Python as web language over others such as PHP or ASP.NET. Of course this depends on what you are doing, but many developers I know argue that, they can do anything they need in .NET.
However, the Django framework seems to really make Python based web app development very intuitive. Now, it would take me forever to build in the same functionality with my Django app as I get out of the box with Plone/Zope, but Django's sensible structure and readability makes it a great environment for developers use to the PHP or ASP approaches.
For years this has been my primary gripe with Python. Though it is a great language, building web apps with Python has been horrible. With PHP I could get going immediately. Likewise, I learn by doing. All the PHP tutorials are designed to teach PHP programming in the context of web development. In a sense you get instant results. With Python you spend 80% of the time learning the spelling without producing anything.
However, with Django you start building apps immediately! In fact I was able to build a simple blog app within an hour or so using Django (BTW, VERY simple), similar to the time it takes me when using PHP. The cool thing is again, I can more readily use Python in my small web projects and stick with Plone for my larger projects. Pretty nice!
But if you are someone interested in learning Python then I would start with the Python Phrasebook and get cracking on the Django docs/tutorials. This is a very PHP way to go, but your code will benefit being object-centric from the get go, plus Django makes use of a nice ORM where as PHP seems lacking in this area.
Now, don't get me wrong don't let your PHP skills slack, despite my interest in Python most of the projects I get asked to work on are still focused on PHP and not Python. Yet that has been changing and knowing Python and understanding the power of a framework like Django or an application like Plone gives you some flexibility.
This steep learning curve, which feels now even steeper seems to make it hard to get new developers to utilize Python as web language over others such as PHP or ASP.NET. Of course this depends on what you are doing, but many developers I know argue that, they can do anything they need in .NET.
However, the Django framework seems to really make Python based web app development very intuitive. Now, it would take me forever to build in the same functionality with my Django app as I get out of the box with Plone/Zope, but Django's sensible structure and readability makes it a great environment for developers use to the PHP or ASP approaches.
For years this has been my primary gripe with Python. Though it is a great language, building web apps with Python has been horrible. With PHP I could get going immediately. Likewise, I learn by doing. All the PHP tutorials are designed to teach PHP programming in the context of web development. In a sense you get instant results. With Python you spend 80% of the time learning the spelling without producing anything.
However, with Django you start building apps immediately! In fact I was able to build a simple blog app within an hour or so using Django (BTW, VERY simple), similar to the time it takes me when using PHP. The cool thing is again, I can more readily use Python in my small web projects and stick with Plone for my larger projects. Pretty nice!
But if you are someone interested in learning Python then I would start with the Python Phrasebook and get cracking on the Django docs/tutorials. This is a very PHP way to go, but your code will benefit being object-centric from the get go, plus Django makes use of a nice ORM where as PHP seems lacking in this area.
Now, don't get me wrong don't let your PHP skills slack, despite my interest in Python most of the projects I get asked to work on are still focused on PHP and not Python. Yet that has been changing and knowing Python and understanding the power of a framework like Django or an application like Plone gives you some flexibility.
Friday, August 31, 2007
Tech Stack for PSP
So, I have been thinking of this online pattern mapping system for sometime. A part of this process, (aside from defining the requirements) has been heavily devoted to researching existing technologies through which to approach this massive project. While there are similar projects taking place and that this system might be able draw from or integrate well with (such as the GreenMaps), it is apparent that this is going to be a home grown PSP sponsored software project. Which means we need to get moving in the direction of understanding our basic recs and identify our technologies.
Considering that the new PSP site is going Joomla 1.5 I have been leaning much more heavily towards a PHP framework like Symfony. I have been a pro Django guy since being a pro-Python coder (yes, I LUV PYTHON, so there!). However, it is clear to me that with all the people working on this project the one thing we seem to have in common, skill-set wise is a fairly deep collective knowledge of PHP. Beyond PHP some of us know Ruby and some know Python, and there are some that are more fluent in Perl. Now, I don't mind learning a new application framework, as long as the framework is in a language I already know, meaning any of the gazillion PHP or Python frameworks are fine. But I really don't have the time to learn an entirely knew programming language along with the framework.
Now, I know that sounds crude to some as one always chooses the best technology for the job, but I have seen similar apps written in all three of these frameworks. Here is a Symfony one for show "MySpaceMaps." So, while I think there is always the argument for best technology for the job, I think after a certain point it becomes about what developers are most comfortable with; where are they going to be most productive and considering the resources and skill-sets of a completely volunteer run non-profit, where is the space that can enable us to all work collaboratively.
Plus, as hard as it is to believe I do have a life!
So, I'm hoping that something like Symfony can be powerful enough for us to achieve our goals but be something that can bring the interested developers together so that we can develop this tool in more collaborative context rather than relying on the expertise and availability of one individual.
One, that isn't fair to that individual, two that is a lot of reliance on one person and three I think those interested in the project like to code, so hopefully it is using tools we all know, and know that work so that we can work together.
Considering that the new PSP site is going Joomla 1.5 I have been leaning much more heavily towards a PHP framework like Symfony. I have been a pro Django guy since being a pro-Python coder (yes, I LUV PYTHON, so there!). However, it is clear to me that with all the people working on this project the one thing we seem to have in common, skill-set wise is a fairly deep collective knowledge of PHP. Beyond PHP some of us know Ruby and some know Python, and there are some that are more fluent in Perl. Now, I don't mind learning a new application framework, as long as the framework is in a language I already know, meaning any of the gazillion PHP or Python frameworks are fine. But I really don't have the time to learn an entirely knew programming language along with the framework.
Now, I know that sounds crude to some as one always chooses the best technology for the job, but I have seen similar apps written in all three of these frameworks. Here is a Symfony one for show "MySpaceMaps." So, while I think there is always the argument for best technology for the job, I think after a certain point it becomes about what developers are most comfortable with; where are they going to be most productive and considering the resources and skill-sets of a completely volunteer run non-profit, where is the space that can enable us to all work collaboratively.
Plus, as hard as it is to believe I do have a life!
So, I'm hoping that something like Symfony can be powerful enough for us to achieve our goals but be something that can bring the interested developers together so that we can develop this tool in more collaborative context rather than relying on the expertise and availability of one individual.
One, that isn't fair to that individual, two that is a lot of reliance on one person and three I think those interested in the project like to code, so hopefully it is using tools we all know, and know that work so that we can work together.
Subscribe to:
Posts (Atom)