I’m looking to start developing a simple task management application
with a web interface.Three views - User/Admin/Status. No database yet
as i think that would be overkill. I intend to store the data in xml
files for the moment.
My question - i am pretty new to development. I have been working as a
qa engineer for some time and have good unix skills but have only ever
really played with java/perl with no great success. Have had enough of
wishing for applications or features. I’m going to write my own.
I would appreciate any pointers the group could offer. For starters i
am unsure if i should develop in vanilla ruby or implement ruby on
rails if it is to be a web application. My initial thoughts are that
learning ruby will be enough for a start but that i may have to use
some MVC model??
I have hosting with dreamhost which supports ruby.
I am currently expanding the spec and a simple UI which i can post
when complete if people think that would be useful. Its based loosely
on basecamphq but more aligned to the organisation i work for and i
would hope to make it very portable.
I’d say your best bet would be to start with a couple of Ruby
tutorials to get a hang of the idioms (blocks being one of the most
important ones) that make Ruby easy to use and maybe try writing a few
small programs in Ruby (preferablly ones that you’d actually use) and
then jump into Rails.
Even as a beginner you shouldn’t have too much trouble using Rails,
but you definitley benefit from understanding where and how its power
and flexibility come from.
Chris P.'s tutorial is supposed to be very good even for people
who’ve never programmed before (I haven’t read it personally): http://pine.fm/LearnToProgram/
I personally learned Ruby from the Pickaxe v2, which I found to be the
best book on a programming language that I’ve ever read (version 1 is
available online: Programming Ruby: The Pragmatic Programmer's Guide
As for Rails, I personally couldn’t get much out of most of the online
documents on it. I got the Agile Web D. book and that
cleared up a lot for me. In any case here’s a list of Rails tutorials
and documentation, youre mileage may vary:
I completely agree with Jules: try Rails from the start and learn Ruby
as you go. When you encounter some ruby “feature” you don’t know,
google for it and see what it does. That way you’ll be happy to have
your app quickly and you’ll learn exactly those parts of ruby you need.
Thanks to everybody for the recommendations. I had a lot of the links
lined up and ready to read , will jump into rails straight away. I am
still a little reluctant to start off my first real project with a
Database back end.I’m concerned that the design and management of the
database could add a serious jump in my already steep learning curve.
If anybody has the time would the be kind enough to outline the pro’s
of using a database agains the cons of xml.
My initial thoughts when choosing xml was that it is easily
manipulated, can be easily accessed by other applications and that if
in the future i did want to go to a database it would lend itself to
migration?
Thanks to everybody for the recommendations. I had a lot of the links
lined up and ready to read , will jump into rails straight away. I am
still a little reluctant to start off my first real project with a
Database back end.I’m concerned that the design and management of the
database could add a serious jump in my already steep learning curve.
You may be interested to know that we shall shortly (within the next
month
or so) be starting a ‘Programming Ruby’ series on the Bitwise Magazine
site www.bitwisemag.com . It is our intention to concentrate purely on the
Ruby
language for the first few months, only moving on to Rails (and a few
other
things) at a later stage. My own view is that while Rails may have, to
large
extent, generated a great deal of recent interest in Ruby, it is all too
easy to become seduced by the special features of Rails for creating
powerful applications with relatively little programming with the
consequence that this may ‘hide’ the features of Ruby itself. We
therefore
decided that a logical approach for our coverage would be to concentrate
entirely on the Ruby language initially and only move into graphical and
web
application development at a later stage.
I’m concerned that the design and management of the
database could add a serious jump in my already steep learning curve.
I’ll take the road less traveled and recommend you stick with your
first instinct which was not to use Rails. I know most people say
it’s so easy to learn and it is, for a web development framework.
However, the key there is that there is more to learn.
Plus, Rails sits on top of Ruby, so starting at the top means you
might be a little fuzzy down the road about what is a Railsism and
what is actually part of the language. I think it’s much easier to
go in the other direction, after you have a solid foundation in the
language, though I’m probably in the minority with this line of thought.
Your needs sounded very modest, so you should be able to easily get
something going with the language itself and the help of one or two
standard libraries. Here are my recommendations:
Use CGI or WEBrick servlets to handle the logic. These are very
low-tech compared to Rails, but trivial to get going.
Give YAML a shot, before you resort to using XML. I’m just
saying that because I think you will be surprised by how much easier
it is in Ruby. You will likely be able to save all your data with a
single line of code and load it with another line. It very painless.
Ask us any questions you run into along the way.
Good luck with your project, however you decide to approach it.
I’ll take the road less traveled and recommend you stick with your
first instinct which was not to use Rails. I know most people say
it’s so easy to learn and it is, for a web development framework.
However, the key there is that there is more to learn.
Plus, Rails sits on top of Ruby, so starting at the top means you
might be a little fuzzy down the road about what is a Railsism and
what is actually part of the language. I think it’s much easier to
go in the other direction, after you have a solid foundation in the
language, though I’m probably in the minority with this line of thought.
I hope not, as I feel the same way, and this seems very rational.
Personally, I read Pickaxe Dos before writing a single line of Ruby,
much less Rails, and I feel it was very beneficial going into Rails. I
believe it has provided for less frustration with a great many details,
and enabled me to think smarter about how to do and even extend Rails
as I keep on learning.
rails tutorials are very glitzy but they are scary as you may not
understand any of it
this tutorial is low key, but it explains things pretty well - I have
not finished it
no installation (written in ruby) : put kirbybase.rb in
c:\ruby\lib\ruby\site_ruby and that’s all
no database language to learn : everything is done with ruby syntax
no administration tools required : the data is in plain text files
no hundreds of page to read : the complete doc is 77k
offers nearly the power of a “real” database system : indexes, lookup
tables, one-to-many links, multi-fields sort, enough data types (String,
Integer, Float, Boolean, Time, Date, DateTime, Memo, Blob, and YAML.)
Thanks for your words of encouragement. Sage indeed. I’m going to start
with ruby and work my way up. YAML seems to be exactly what i am
looking for. I had not run across it before.I also like the look of
webrick. I really want to keep things as simple as possible. Its a lot
to take in but exciting.
I’m finishing up my simple design and will post it here soon so folks
can take a look if they have the time or inclination. I must reiterate,
I am new to development so mistakes will be made, bugs will be logged
and hands will be wrung, just go easy.
With regard to the design, for a web application i understand MVC
pattern is very popular, we use it a lot where i work. For my
application i’m trying to figure out where everything lives. This is
proving to me a challenge.
Hate to spoil a perfectly good sales pitch, but if the app is supposed
to be
in Rails and simple / formulaic enough, it doesn’t really matter what
the
underlying query language is.
Is there a usable Rails adapter for KirbyBase? ACID transactions (for DB
schema changes if nothing else)?
And with the good and bad of it, SQL is -the- standard RDBMS query
language,
so that would restrict KirbyBase to small / personal projects where
you’re
sure you’ll never change DB backends.
Also, why would someone that already knows SQL choose KirbyBase over
SQLite?
The latter installs very easily too.
David V.
PS: No, I’m not trying to flame KirbyBase, or sales pitches. Just if
you’re
going to do a sales pitch for whatever you like, make it less mindless
and
put it into context.
DÅ?a Å tvrtok 09 Február 2006 22:18 Alain FELER napÃsal:
Thanks Alain, Kirbybase does look like a very nice solution. It has
given me some food for thought. I keep asking myself what a database
gives me over XML or yaml for a simple application like mine that will
only ever contain name value pairs or a basic extension of this format.
I’d like a little info on what i will gain by using a DB. At the moment
i see it as a lot of overhead and maybe a step to far.
Although the more i look at kirbybase the more i do like some of the
features and its simplicity.
Hate to spoil a perfectly good sales pitch, but if the app is
supposed to be
in Rails and simple / formulaic enough, it doesn’t really matter
what the
underlying query language is.
Is there a usable Rails adapter for KirbyBase? ACID transactions
(for DB
schema changes if nothing else)?
Well if he’s considering not using Rails at all it doesn’t matter if
there’s an ActiveRecord adapter for it (although I’ve written an AR
ripoff for KB, there’s an Og adater for it, and I know someone is
working on a ActiveRecord adapter for KB). I don’t believe KB is
ACID, although I could be wrong
And with the good and bad of it, SQL is -the- standard RDBMS query
language,
so that would restrict KirbyBase to small / personal projects where
you’re
sure you’ll never change DB backends.
Not true, KirbyBases’ format is easily parseable and editable by hand
as well. It also accessible from Python.
Also, why would someone that already knows SQL choose KirbyBase
over SQLite?
The latter installs very easily too.
Well kirbybase is precisely 1 file of ruby sourcecode. Doesn’t get
much easier than that, especially if you need to deploy elsewhere.
Thanks Alain, Kirbybase does look like a very nice solution. It has given me
some food for thought. I keep asking myself what a database gives me over
XML or yaml for a simple application like mine that will only ever contain
name value pairs or a basic extension of this format.
I’d like a little info on what i will gain by using a DB. At the moment i
see it as a lot of overhead and maybe a step to far.
concurrency
a web enabled program means multiple users accessing the data
source at
once. unless you are willing for one user to block all others
while a
lock is held you will corrupt the data store
atomicity
transactions allow you to bundle changes into all or none
operations
consistency
only valid data may be wrttien. validation data in your
application is
fine. until another app accesses the data and hoses it.
validate in
the db.
isolation
if something from db
then modify db
works for multiple process at once. each sees a view of the db
that makes
it appear as if it’s the only process accessing it.
durability
power failures, disk failures, etc are far less likely to corrupt
your
data. especially since you’ll have the option of hot backups
standards
sql helps keep data logic out of your code. for instance,
thousands of
reporting tools and applications will just ‘work’ with your data.
effort. if your are talking rails it like about 1000000% times
easier to
use a db than not.
scalability. if your application is good you may want to add a
feature
or users. a db makes that possible.
some applications can definitely make use of yaml, bdb, pstore, fsdb,
kirbybase, etc. but web aps push their limitations for sure.
DÅ?a Å tvrtok 09 Február 2006 23:26 Logan C. napÃsal:
On Feb 9, 2006, at 5:01 PM, David V. wrote:
And with the good and bad of it, SQL is -the- standard RDBMS query
language,
so that would restrict KirbyBase to small / personal projects where
you’re
sure you’ll never change DB backends.
Not true, KirbyBases’ format is easily parseable and editable by hand
as well. It also accessible from Python.
I said switching DB -backends-, not what I access it with. I can to some
extent drop one SQL DBMS in place of another without changing the code
accessing it. I can’t for example use KB to prototype an application and
then
switch over to Postgres for scalability without rewriting my DB query
code.
This is of course not an issue when using an ORM layer, and use of SQL
doesn’t
quite save you from having to do DB migration - even if dumping the
schema
and data as SQL statements might help. Sounds like a potentially useful
feature for KB, is it already present? If not, it sounds arguably
somewhat
easier to implement than a KB query-to-SQL compiler.
Also, why would someone that already knows SQL choose KirbyBase
over SQLite?
The latter installs very easily too.
Well kirbybase is precisely 1 file of ruby sourcecode. Doesn’t get
much easier than that, especially if you need to deploy elsewhere.
SQLite is one DLL, and one gem installation. I’ve walked managers
through
that. More complicated, yes, but I can’t imagine a deployment scenario
where
on would pose significantly more problems than the other. Well, except
atomically packaging the application as a gem.
