Ok, I have a question from a "client" perspective. Let's say we are talking about website designed for distribution: products + their logistics info.
Definitely less than a 2k rows, rarely changed but often accessed. Typical row with several columns will have to consist of a picture so it might make it a bit "heavy". I was proposed a websited in Django Framework coded in Python with Postgresql database.
Is it efficient? Cost-efficient, for such a small purpose is it really needed? and is there a cheaper and also reliable solution?
From what I know the porposed solution is efficient for a programmer - loads of features, flexibility, distinction between layers of code-content-graphics. It gives a chance to build rly complicated websites and databases - thus the cost of service is bigger.
What i need to know is whether the porposed solution is suitable for such a small project and could not be easily replaced by less complicated languages/frameworks/dmbses like PHP with MySQL etc.
Please help :]
and sry for not editing the q in the first place
"What i need to know is whether the porposed solution is suitable for such a small project and could not be easily replaced by less complicated languages/frameworks/dmbses like PHP with MySQL etc.
"
Yes. It's suitable.
No. Nothing is "less complicated" than Django. PHP language may appear less complicated than Python, but you'll do more work to create the site.
With Django, you define the model, define the non-administrative views and you're done. For simple sites this can take as little as 20 minutes. The built-in admin is more valuable than you can imagine.
MySQL is not "less complicated" that PostgresSQL -- they're the same thing
I would not comment about Django & Python. But a more simpler way to store images would be to store just the "path" (location in the directory) in the tables, and load the path in your application/framework.
Website For small webservices you can use micro-frameworks like http://www.sinatrarb.com/ (which is written in ruby); you write simple and useful apps in a few dozens or hundreds of lines. Plug your database in via some object-relational mapper and you should have a working prototype within a few hours/days.
PDF For PDF generation, there is some great ruby library by Gregory Brown called prawn ...
Addendum A python/django solution isn't complicated/un-effective either ...
Related
I've been developing with Django during the last year or so and really
enjoy it. But sometimes I find that the ORM is a bit of a
straitjacket. All the data that I shuffle back and forth to the
database would easily fit into 1GB of RAM. Even if the project grew a
couple of orders of magnitude it would still fit into 1GB.
I'd like a solution where my application only needs to read from disk
at startup but writes to disk implicitly as I update my objects. I
don't care to much about any speed increase this might give me. What
I'm really after is the added flexibility. If I have a problem that
would fit nicely with a linked list or a tree or some other
data structure, I shouldn't have to graft that onto a relational
database.
Python would be nice but other languages are fine. I'm in the exploratory
phase on this one. I want to get a feel for what solutions are
out there. When googling this question I got a lot of hits related to
different Nosql projects. But Nosql, as I understand it, is all about
what you do when you outgrow relational databases because you've got too
much data. I'm really at the other end of the spectrum. I've got so
little data that a relational database is actually overkill.
Object databases is an
other thing that came up when googling this question, which reminded
me of Zope and ZODB. I dabbled a bit with Zope an eon ago and really
disliked it. But reading up a bit on object databases made me think that it
might what I'm looking for. Then again, their general failure to
attract users makes me suspicious. Object databases have been around
for a very long time and still haven't caught on. I guess
that means there's something wrong with them?
If you are looking for "storing data-structures in-memory" and "backing up them to disk", you are really looking for a persistent cache system and Redis fits the bill perfectly.
If you want to use django, there is an awesome cache system built-in and that is pluggable to redis backend via Redis-Cache project. More over the data-structures accomodated by redis have one-to-one mapping to python data-structures, and so it is pretty seamless.
I am not so sure if skipping the concept of database itself, is a good idea. Database provides so much power in terms of aggregating, annotating, relations etc, all within acceptable performance levels until you hit real large scale.
Perhaps another idea would be to to use SQLite in-memory database. SQLite is so ubiquitous these days, it has disappeared into the infrastructure. It is built in, Android apps, iphone ones and has support from all standard libraries. It is also an awesome software developed and tested so well, it is very hard to make any case against using it.
The company I work for (Starcounter) creates a database that works exactly in the way that you describe. We have been running the database for a few years with our partner customers and are about to make the product publicly available. The main reason we created it is for ease of use and performance. I'll be happy to send you a copy if you send me a message on our corporate forum (I’m Starconter Jack).
On the subject on OO databases; the reason that OO databases failed is mainly because they were more experiments than real products. They were poorly implemented, supported only the OO paradigm and ignored standards such as SQL and ODBC. They also lacked stability, performance and maturity. Their story is analogues to the early tablets, eBooks and smartphones a decade or two before the iPhone, iPad and Kindle.
But just as with any technology, there are two waves (look up "the hype cycle"). While the first wave will disappoint, the second wave will be good. The first one will be driven by the concepts and ideas and will lack commercial success and real life usability. The second wave will want nothing to do with the musty smell of the failures of the first one and will therefore use new and fresh acronyms and buzzword.
The future database will spring out of the NoSQL movement. It will have added SQL support and many will think this is novel. It will have added good language integration (and most languages are oo) and many will think this is also novel. It will support documents and many will think this will be novel. Many will rediscover the need for transactions etc. etc.
Some grumpy old men will try to tell us that all we have done is to reinvent existing ideas. In some way they will be right; in some ways they won’t. This time around, the concepts are matured. New ideas will be added and pragmatism will be allowed.
But then again, an iPad is still, in a way, a PDA.
I was wondering what the performance difference is between using plain python files to make web pages and using Django. I was just wondering if there was a significant difference between the two. Thanks
Django IS plain Python. So the execution time of each like statement or expression will be the same. What needs to be understood, is that many many components are put together to offer several advantages when developing for the web:
Removal of common tasks into libraries (auth, data access, templating, routing)
Correctness of algorithms (cookies/sessions, crypto)
Decreased custom code (due to libraries) which directly influences bug count, dev time etc
Following conventions leads to improved team work, and the ability to understand code
Plug-ability; Create or find new functionality blocks that can be used with minimal integration cost
Documentation and help; many people understand the tech and are able to help (StackOverflow?)
Now, if you were to write your own site from scratch, you'd need to implement at least several components yourself. You also lose most of the above benefits unless you spend an extraordinary amount of time developing your site. Django, and other web frameworks for every other language, are designed to provide the common stuff, and let you get straight to work on business requirements.
If you ever banged out custom session code and data access code in PHP before the rise of web frameworks, you won't even think of the performance cost associated with a framework that makes your job interesting and eas(y)ier.
Now, that said, Django ships with a LOT of components. It is designed in such a way that most of the time, they won't affect you. Still, a surprising amount of code is executed for each request. If you build out a site with Django, and the performance just doesn't cut it, you can feel free to remove all the bits you don't need. Or, you can use a 'slim' python framework.
Really, just use Django. It is quite awesome. It powers many sites millions times larger than anything you (or I) will build. There are ways to improve performance significantly, like utilizing caching, rather than optimizing a loop over custom Middleware.
Depends on how your "plain Python" makes web pages. If it uses a templating engine, for instance, the performance of that engine is going make a huge difference. If it uses a database, what kind of data access layer you use (in the context of the requirements for that layer) is going to make a difference.
The question, thus, becomes a question of whether your arbitrary (and presently unstated) toolchain choices have better runtime performance than the ones selected by Django. If performance is your primary, overriding goal, you certainly should be able to make more optimal selections. However, in terms of overall cost -- ie. buying more web servers for the slower-runtime option, vs buying more programmer-hours for the more-work-to-develop option -- the question simply has too many open elements to be answerable.
Premature optimisation is the root of all evil.
Django makes things extremely convenient if you're doing web development. That plus a great community with hundreds of plugins for common tasks is a real boon if you're doing serious work.
Even if your "raw" implementation is faster, I don't think it will be fast enough to seriously affect your web application. Build it using tools that work at the right level of abstraction and if performance is a problem, measure it and find out where the bottlenecks are and apply optimisations. If after all this you find out that the abstractions that Django creates are slowing your app down (which I don't expect that they will), you can consider moving to another framework or writing something by hand. You will probably find that you can get performance boosts by caching, load balancing between multiple servers and doing the "usual tricks" rather than by reimplementing the web framework itself.
Django is also plain Python.
See the performance mostly relies on how efficient your code is.
Most of the performance issues of software arise from the inefficient code, rather than choice of tools and language. So the implementation matters. AFAIK Django does this excellently and it's performance is above the mark.
I need to make a tabular data structure (tab delimited text file) available for viewing as a web based solution. I am a bioinformatics programmer with almost no experience in web based development. I know that django is very hot in the python community but I wanted to ask here before I went ahead and buy a book on django. What would be your choice of technology stack to accomplish something like this.
I need to display a table of 40-50 columns and 100.000 rows and hopefully let the user filter the data based on certain data items ( i.e only show rows that have a certain value in a certain column , show only data that was recorded on Monday and hide all other weekdays)
I am sorry if this question is too vague or stupid but I really need some basic guidance here.
Thanks
Django can do this fairly easily.
Django can do this, but I think the best way to go is to use a Javascript framework ontop of django, I am currently doing this. ExtJS has various types of grids in your situation I think a 'Live' grid would be perfect.
It loads x amount of rows, so that you dont have to load 100,000 rows everytime, just what the user sees. Also, filters etc are built in as well as many other features
Other javascript frameworks that do similar things are YUI and in my opinion JQuery to a lesser extent
Edit/Elaborate
So obviously here isnt the place for a beginners crash course, but in my opinion there is a couple of things you need to do and know.
This will work by firstly creating a django view that returns a JSON string. (If that sentence didnt make a whole bunch of sense, I would recommend skimming over the Django tutorial...actually, you probably should do that anyway) Python has methods to turn datatypes such as dictionaries/csv's (in your case, I guess a TSV lol) to this format. THEN, when you have this (can be pointed to by a url...when you dive into Django it will make more sense) then you create the ExtJS grid and point it to that url.
There is a whole bunch of tutorials about ExtJS grids here, notably the Tutorial:Grid PHP SQL I think would be helpful. Obviously not php, but the concept is the same.
Unfortunately I dont have any examples of my own to show you, but there are TONS of resources about this stuff, I wouldnt bother buying a book
I think this could be done easily without JavaScript. What neolaser is outlining is my preferred solution as well, but django could do this no sweat. You would need
to configure your models.py to match your database
a view that accepts get requests and makes queries based off of their contents. http://docs.djangoproject.com/en/dev/ref/models/querysets/
a template that displays the results of those queries and allows you make get requests which your view will interpret.
Because django is such a well-used framework, it's pretty easy to find a run down on the various terms (google: "django views", "django models", etc).
If what you describe is really all you're doing, then I'd say Django may be overkill. Maybe first try a simpler basic framework like Cherrypy (see tutorial) to serve your simple page/form (you don't even need templates, just spit back HTML yourself). Now all you need is a bit of code to read, filter and/or page, and format your CSV.
If you want to put something like this together very quickly and easily and you don't have much web development experience, I think your best bet would be web2py. It requires no installation or configuration, has no dependencies, and includes a web server, a relational database, a web-based integrated development environment and admin interface (demo), and jQuery integration (for Javascript and Ajax). It's very easy to learn and was designed for ease of use and developer productivity. You can get a lot done with very little code thanks to the included scaffolding app along with many sensible default behaviors.
As for table/grid displays, you could probably use:
The jqGrid plugin - a web2py plugin for jqGrid
powerTable (source code) - a web2py plugin for DataTables
If you need help getting started or have any questions, you'll get lots of help from the very friendly and responsive mailing list.
I have to develop a site which has to accomodate around 2000 users a day and speed is a criterion for it. Moreover, the site is a user oriented one where the user will be able to log in and check his profile, register for specific events he/she wants to participate in. The site is to be hosted on a VPS server.Although I have pretty good experience with python and PHP but I have no idea how to use either of the framework. We have plenty of time to experiment and learn one of the above frameworks.Could you please specify which one would be preferred for such a scenario considering speed, features, and security of the site.
Thanks,
niting
This is a very subjective question but personally I'd recommend Django. Python is a very nice language to use and the Django framework is small, easy to use, well documented and also has a pretty active community.
This choice was made partly because of my dislike for PHP though, so take the recommendation with a pinch of salt.
Most of the frameworks out there nowadays are fast enough to serve whatever needs you will have. It really depends on in which environment you feel most comfortable. Though there are nuances here and there, MVC frameworks share a lot of the same principles, so whichever you choose to use is really a matter of which you most enjoy using.
So, if you like Python more, there's your answer. Use a Python framework, and Django is the best. If you like PHP more (which I personally don't), you've got some more decisions to make. But any of the PHP frameworks are fine. They really are. Just pick one that looks nice with comprehensive documentation and get to work.
I've worked with CakePHP and Django and I really recommend Django. I don't know too much about CodeIgniter, but I remember ruling it out when I was evaluating frameworks myself about a year ago. CakePHP seemed much more developed at the time.
First of all, the Django community is much bigger and has spent a lot of time focusing on reusable apps. This means that you get a lot of functionality for free. Pair this with the django admin, and you have a lot of things already done for you. I haven't kept up with the PHP frameworks much, but I'm pretty sure Django is also more developed.
This is more of a personal thing, but I just like Python over PHP. Compare the way models are done in CakePHP and Django: http://book.cakephp.org/view/67/Understanding-Models, http://docs.djangoproject.com/en/dev/topics/db/models/#topics-db-models. The python is clearly more readable.
Keep in mind that Django gives you an awesome ORM and builds your schema for you, i.e. you never have to touch the database if you don't want to. With the PHP frameworks, you have to do your own db design, which just slows me down at this point. You can always go in and add indexes for speed later.
This is probably the most biased, but if you are starting a new application - seriously - just stick with Django or Ruby on Rails. There is a reason everyone talks about them and they have the biggest communities and best developers behind them.
You can also check out Pinax for a lot of Django goodies.
Codeigniter it's fast and very documented also has a large community to and finaly friendly with the programmer.
CodeIgniter is a great PHP framework that is fast and has excellent documentation. Start reading through their user guide and it will give you a good idea how to work with the framework.
Extending Matchu:
Or, -If you like PHP more- its time to learn/growup about other things like Python. Its not hard to learn, and when you get started it gets very enjoyable.
Many people has done the PHPtoPython/Django port, like Mozilla, Netgeo, Nasa, TheOnion, etc.
If for the PHP part I would choose CodeIgniter - it doesn't get too much into your way. But it doesn't have any code/view/model generators out of the box, you need to type a bit.
But languages other than PHP appear to be more sexy.
I am using CodeIgniter 1.7.2 and for complex websites it's very good and powerfull, but it definitely is missing some kind of code generator which will allow for example to build an IT application in one click.
I had the impression (from watching a tutorial) that Django has it.
A few weeks ago I asked the question "Is a PHP, Python, PostgreSQL design suitable for a non-web business application?" Is a PHP, Python, PostgreSQL design suitable for a business application?
A lot of the answers recommended skipping the PHP piece and using Django to build the application. As I've explored Django, I've started to question one specific aspect of my goals and how Django comes into play for a non-web business application.
Based on my understanding, Django would manage both the view and controller pieces and PostgreSQL or MySQL would handle the data. But my goal was to clearly separate the layers so that the database, domain logic, and presentation could each be changed without significantly affecting the others. It seems like I'm only separating the M from the VC layers with the Django solution.
So, is it counterproductive for me to build the domain layer in Python with an SQL Alchemy/Elixir ORM tool, PostgreSQL for the database layer, and then still use Django or PHP for the presentation layer? Is this possible or pure insanity?
Basically, I'd be looking at an architecture of Django/PHP > Python/SQLAlchemy > PostgreSQL/MySQL.
Edit: Before the fanboys get mad at me for asking a question about Django, just realize: It's a question, not an accusation. If I knew the answer or had my own opinion, I wouldn't have asked!
You seem to be saying that choosing Django would prevent you from using a more heterogenous solution later. This isn't the case. Django provides a number of interesting connections between the layers, and using Django for all the layers lets you take advantage of those connections. For example, using the Django ORM means that you get the great Django admin app almost for free.
You can choose to use a different ORM within Django, you just won't get the admin app (or generic views, for example) along with it. So a different ORM takes you a step backward from full Django top-to-bottom, but it isn't a step backward from other heterogenous solutions, because those solutions didn't give you intra-layer goodness the admin app in the first place.
Django shouldn't be criticized for not providing a flexible architecture: it's as flexible as any other solution, you just forgo some of the Django benefits if you choose to swap out a layer.
If you choose to start with Django, you can use the Django ORM now, and then later, if you need to switch, you can change over to SQLalchemy. That will be no more difficult than starting with SQLalchemy now and later moving to some other ORM solution.
You haven't said why you anticipate needing to swap out layers. It will be a painful process no matter what, because there is necessarily much code that relies on the behavior of whichever toolset and library you're currently using.
Django will happily let you use whatever libraries you want for whatever you want to use them for -- you want a different ORM, use it, you want a different template engine, use it, and so on -- but is designed to provide a common default stack used by many interoperable applications. In other words, if you swap out an ORM or a template system, you'll lose compatibility with a lot of applications, but the ability to take advantage of a large base of applications typically outweighs this.
In broader terms, however, I'd advise you to spend a bit more time reading up on architectural patterns for web applications, since you seem to have some major conceptual confusion going on. One might just as easily say that, for example, Rails doesn't have a "view" layer since you could use different file systems as the storage location for the view code (in other words: being able to change where and how the data is stored by your model layer doesn't mean you don't have a model layer).
(and it goes without saying that it's also important to know why "strict" or "pure" MVC is an absolutely horrid fit for web applications; MVC in its pure form is useful for applications with many independent ways to initiate interaction, like a word processor with lots of toolbars and input panes, but its benefits quickly start to disappear when you move to the web and have only one way -- an HTTP request -- to interact with the application. This is why there are no "true" MVC web frameworks; they all borrow certain ideas about separation of concerns, but none of them implement the pattern strictly)
You seem to be confusing "separate layers" with "separate languages/technologies." There is no reason you can't separate your concerns appropriately within a single programming language, or within an appropriately modular framework (such as Django). Needlessly multiplying programming languages / frameworks is just needlessly multiplying complexity, which is likely to slow down your initial efforts so much that your project will never reach the point where it needs a technology switch.
You've effectively got a 3 layer architecture whether you use Django's ORM or SQLAlchemy, though your forgo some of the Django's benefits if you choose the latter.
Based on my understanding, Django would manage both the view and controller pieces and PostgreSQL or MySQL would handle the data.
Not really, Django has its own ORM, so it does separate data from view/controller.
here's an entry from the official FAQ about MVC:
Where does the “controller” fit in, then? In Django’s case, it’s probably the framework itself: the machinery that sends a request to the appropriate view, according to the Django URL configuration.
If you’re hungry for acronyms, you might say that Django is a “MTV” framework – that is, “model”, “template”, and “view.” That breakdown makes much more sense.
At the end of the day, of course, it comes down to getting stuff done. And, regardless of how things are named, Django gets stuff done in a way that’s most logical to us.
There's change and there's change. Django utterly seperates domain model, business rules and presentation. You can change (almost) anything with near zero breakage. And by change I am talking about meaningful end-user focused business change.
The technology mix-n-match in this (and the previous) question isn't really very helpful.
Who -- specifically -- benefits from replacing Django templates with PHP. It's not more productive. It's more complex for no benefit. Who benefits from changing ORM's. The users won't and can't tell.