Hello I'm trying to improve my ruby knowledge by reading The Ruby Programming Language book. Reading Coders at work I saw that lot of the interviewees suggest to dive into a project source code
to learn best practices
to be aware of bad habits
and of course to take new inspirations for how to do things.
I decided to pick a project as more self contained as I could find. My choice was Sinatra since It's 1000 LOC.
Is It a good project to learn?
Do you suggest another one more simple (i.e. less LOCs)?
I've tried to see rails machinery before but I came out scared from It.
I'm not that much into Ruby (although I've played a little bit with Sinatra), but I want to say that the Coders at Work advice should rather be read as "read source code not only from one project, but from many". We learn best by comparison. That's also how we're able to spot patterns and abstract them away.
So maybe you can choose some topic from Sinatra, see how it is implemented, then compare it with the way it's done in Rails.
The more sources you consider the better you understand a particular subject.
Reading the Sinatra code is a good start. You might also want to read up on Rack, the HTTP interface Sinatra uses. Not necessarily for coding practices but just to understand how Sinatra fits in the whole stack.
Adding to Ionuț's answer, Rails also uses Rack, so if you decide to look at both Sinatra and Rails, you can compare how they use Rack.
Try typing in gem list to list all the gems you've installed. Pick one that's relevant to your domain.
Related
I have been trying to decide if my web project is a candidate for implementation using PSGI, but I don't really see what good it would do for my application at this stage.
I don't really understand all the fuss. To me PSGI seems like a framework that provides a common interface between different Apache modules which lets you move your application between them. e.g Easily move your application from running on mod_perl to fastcgi, and provide the application support for running on both options.
Is that right, or have I missed something?
As I and the team I am a part of not only develop the application, but also pretty much do maintenance and setup of servers I don't see the value for us of being able to run on fastcgi, cgi, and mod_perl, we do just fine with just mod_perl.
Have I misunderstood the PSGI functionality, or is it just not suitable for my project?
Forget the Apache bit. It's a way of writing your application so that the choice of webserver becomes less relevant. At $work we switched to Plack/PSGI after finding our app running with very high CPU load after upgrading to Apache2 - benchmarking various Apache configs and NYTProf'ing were unable to determine the reason, and using PSGI and the Starman webserver worked out much better for us.
Now everything is handled in one place by our PSGI app (URL re-writes, static content, expiry headers, etc) rather than Apache configuration, so it's a) Perl, and b) easily tested via our standard /t/ scripts. Also our tests are now testing exactly what a user sees, rather than just the basic app itself.
It may well not be relevant to you if you're happy with Apache and mod_perl, and I'm sure others will be able to give much better answers, but for us not having to deal with anything Apache-related again is such a relief in itself. The ease of testing, and the ability to just stick in a Data::Dumper and see what's going on rather than wrestling with ModRewrite and friends, is a great boon.
Borrowing from a recent blog post by chromatic, Why PSGI/Plack Matters (Testing), here's what it is:
It's a good idea borrowed from Python's WSGI and Ruby's Rack but made Perlish; it's a simple formalizing of a pattern of web application development, where the entry point into the application is a function reference and the exit point is a tuple of header information and a response body.
That's it. That's as simple as it can be, and that simplicity deceives a lot of people who want to learn it.
An important benefit is, ibid.,
Given a Plack application, you don't have to deploy to a web server—even locally—to test your application as if it were deployed … Plack and TWMP (and Plack::Test) use the well-defined Plack pattern to make something which was previously difficult into something amazingly easy. They're not the first and they won't be the last, but they do demonstrate the value of Plack.
Started wrote an answer and after 50 lines I deleted it. Simply because it is impossible tell (in short) why is PSGI extremely cool. I'm new in PSGI too, but zilion things now are much easier as before in my apache/mod_perl era.
I can give you next advices:
read the Plack advent calendar - all days, step-by-step. You must understand the basic philosophy, what is good on onions and so on... :)
search CPAN for "Plack::Middleware::" - and read the first few lines in each. Here are MANY. (Really should be somewhere some short overview for each one, unfortunately don't know any faster way. Simply it is good to know, what middlewares are already developed. (For example, you sure will need the Plack::Middleware::Session, or Plack::Middleware::Static and so on...)
read about Plack::Builder (already done, when you done with the advent calendar) :)
try write some apps with it and will find than Plack is like the first sex - now you didn't understand that you could live without it.
ps:
If was here something like "Perl Oscar", will sure nominating MyiagavaSan. :)
looking into connecting to a secure ftp site (using perl), and downloading all the .log files, saving in new directories named after the day I downloaded the files. I want to do this without modules, as a learning experience, but before I start I wanted to know if you guys thought it was doing, or is way too much for a relatively new programmer and I should just learn the modules?
If it's production work, no, use the modules. Your implementation will be buggy, missing features and unknown to the next person maintaining that code.
Otherwise, yes. It's good to learn the principles of a network protocol. I do have a reservation about FTP as it is a bit baroque, insecure, inefficient and on its way out. scp, HTTP or rsync would be more useful to put your energy into.
I'd start with reading the RFC and putting together your own FTP module using just network sockets. Document and test it as if you were going to release to CPAN as a full learning exercise in making a network module. Run it against some various FTP server implementations as they often interpret the spec differently (or not at all). Don't be afraid to cheat and look at what the existing modules do. Who knows, you might write something better than what's already there.
Learning the principals, just like we did at school for long multiplication and division, means we know how things work when we use a short hand.
However, when new to the world,just like when you learn to speak, you did "A is for Apple" etc, you didnt get explained about the finesse of grammar and all that, you learnt to express yourself enough to be understood.
Programming is a little like the same. While in an ideal world you can easily argue a prewritten generic library is often way less efficient than a specifically targeted set of routines. If the wheel you are using was already invented, it seems a lot of work to make a new one.
So, use the wheels and cogs afailable, once you really have the hang of it, NOW look at inventing your own more efficient ones.
Ad cpan modules:
Modules are an great learning source. Here is zilion modules and you can really learn much studying some of them.
And when/while you mastering your perl, you will start writing you own modules. When your program will use modules anyway (yours one), you can ask - why don't use modules already developed and debugged?
So, learn perl basics, study some modules (for example Net::SFTP) and if you still want write your own solution - it is up to you. :)
'
I'm net-java developer with some small projects implemented. I'm going to start a new project which is portal with many typical features (posts, comments, messaging, users, catalog, news, galleries, etc).
I believe the best solution would be use any mature CMS (joomla, drupal...) and customize it where needed. The problem is that I'm not familiar with PHP (CMS written on PHP has far better set of features, plugins, community, information I believe) I'm not planning to learn PHP, I want to improve my java-net skills.
So the question for me is:
write all by myself, improving my programming skills and risking to finish my project in relatively long period
on the other hand
I could spend some time learning tools and languages, which I think while, I don't need in the future and more likely finish my project in some shorter time
what would you advise?
Learning another language will not hurt you, and as most of the differences are in syntax and supporting libraries, you would be surprised at how quickly you can pick up a new language.
Your choice should be on what language is best for the task, not simply the one you know.
So, my suggestion is - learn PHP and go with a mature CMS.
A LOT of effort goes into developing a CMS, so writing your own will likely take some time. Put together a project plan and work out how long it would take you to develop something from scratch, then do some research on existing CMS packages and how they fit your needs.
I'm a .NET developer but have used Joomla in the past - it's actually quite easy to put together a website even if you're not too familiar with PHP.
Better yet, find a CMS package in your preferred language - they oughta be some out there.
i.e.
http://java-source.net/open-source/content-managment-systems
Learning new tools is seldom a waste of time. Especially not when it comes to such well known and world wide spread languages such as php. I would say it's best using the tools most suited for the project you're up to, rather than reinventing the wheel.
You should take a good look at your requirements. If you're sure you can get them all from a CMS, that makes most sense. Take a good look at the compatibility and reliability of all components.
Otherwise, you might be better served by a .net or java CMS.
Writing your own CMS without having extensive experience in the current available ones is not going to lead to a good result, except for you learning some programming skills.
If you don't have a "due date" for your project write it by yourself.
Or take a look at http://www.opencms.org/en/ ;)
There are a lot of opensource CMS written in Java ;)
Even if you don't write in PHP again, the benefit of knowing another programming language is going to give you some valuable perspective on net-java.
The task of learning a new language is going to be an asset. Learning to learn something. Identifying what you need to know and how to find the answers is a transferable skill.
Your job will be to complete your project in the most efficient manner with the highest quality output practical. Use the tool that is going to best help you achieve this. The language it's written in should be largely irrelevant.
I learn best by taking apart something that already does something and figuring out why decisions were made in which manner.
Recently I've started working with Perl's CGI::Application framework, but found i don't really get along well with the documentation (too little information on how to best structure an application with it). There are some examples of small applications on the cgi-app website, but they're mostly structured such that they demonstrate a small feature, but contain mostly of code that one would never actually use in production. Other examples are massively huge and would require way too much time to dig through. And most of them are just stuff that runs on cgiapp, but isn't open source.
As such I am looking for something that has most base functionality like user logins, db access, some processing, etc.; is actually used for something but not so big that it would take hours to even set them up.
Does something like that exist or am i out of luck?
CGI::Application tends to be used for small, rapid-development web applications (much like Dancer, Maypole and other related modules). I haven't seen any real examples of open-source web apps built on top of it, though perhaps I'm not looking hard enough.
You could look at Catalyst. The wiki has a list of Catalyst-powered software and there are a large number of apps there - poke around, see if you like the look of the framework. Of this, this is Perl, so some of those apps will be using Template::Toolkit, some will use HTML::Mason... still, you'll get a general idea.
Try looking at Miril CMS. Although I don't know in which state it is.
I am the same with code, and had the same request. When I did not find a solution I created my own. which is https://github.com/alexxroche/Notice
I hope that it is a good solution to this request.
Notice demonstrates:
CGI::Application
CGI::Application::Plugin::ConfigAuto
CGI::Application::Plugin::AutoRunmode
CGI::Application::Plugin::DBH
CGI::Application::Plugin::Session;
CGI::Application::Plugin::Authentication
CGI::Application::Plugin::Redirect
CGI::Application::Plugin::DBIC::Schema
CGI::Application::Plugin::Forward
CGI::Application::Plugin::TT
It comes with an example mysql schema, but because of DBIC::Schema it can be used with PostgreSQL, (or anything else that DBIx::Class supports.)
I use Notice in all of my real life applications since 2007. The version in github is everything except the branding and the content.
Check out the Krang CMS.
I have inherited a broad, ill-designed web portfolio at my job. Most pages are written in Perl as most of the data ingested, processed, and displayed on the site comes in the form of flat-files which then have to be meticulously regexed and databased in our MySQL and Oracle databases.
As the first IT-trained manager of this environment, I am taking it upon myself to scrub the websites and lay down some structure to the development process. One of the choices I have been given is to choose whether or not to continue in Perl. There is substantial in-house talent for Java and PHP is rather easy to learn. I have considered taking the reins off the developers and letting them choose whatever language they want to use for their pages but that sounds like it might be trouble if the guy who chose PHP gets hit by a bus and no one else can fix it.
As the years go by hiring Perl programmers becomes more and more difficult and the complexity of maintaining legacy Perl code from previous developers whose main focus may have been just getting a page up and running is becoming very resource-consuming. Another, previous (non-IT) manager was more focused in on quick turnaround and immediate gratification of pages rather than ensuring that it was done right the first time (he has since been promoted outside our branch).
The production server is solaris. MySQL has most of our data but new projects have begun using Oracle more and more (for GIS data). Web servers are universally Apache. We live in an intranet disconnected from the regular internet. Our development is conducted in an Agile, iterative manner.
Whatever language is chosen to push forward into, there are resources to have the existing development staff re-trained. No matter what, the data that comes into our environment will have to be regexed to death so perl isn't going away anytime soon. My question to the community is, what are the pros and cons of the following languages for the above-defined web dev environment: Perl, PHP, Java, Python, and --insert your favorite language here--. If you had it to do all over again, which language set-up would you have chosen?
Edits and Clarifications:
Let me clarify a bit on my original post. I'm not throwing everything away. I've been given the opportunity to adjust the course of the ship to what I believe is a better heading. Even if I chose a new language, the perl code will be around for some time to come.
Hypothetically speaking, if I chose Assembly as my new language (haha) I would have to get the old developers up to speed probably by sending them to some basic assembly classes. New pages/projects would be in the new language and the old pages/projects would have to play nice with the new pages/projects. Some might one day be rewritten into the new language, some may never be changed.
What will likely always be in Perl will be the parsing scripts we wrote years ago to sift through and database information from the flat files. But that's okay because they don't interface with the webpages, they interface with the database.
Thank you all for your input, it has been very very helpful thus far.
It seems that your problem is more legacy code and informal development methodology than the language per se. So if you already have Perl developers on staff, why not start modernizing your methods and your code base, instead of switching to a new language, and creating an heterogeneous code base.
Modern Perl offers a lot in terms of good practices and powerful tools: testing is emphasized, with the Test::* modules and WWW::Mechanize, data base interaction can be done through plain DBI, but also using ORM modules like the excellent DBIx::Class, OO with Moose is now on par with more modern languages, mod_perl gives you access to a lot of power within Apache. There are also quite a few MVC frameworks for Perl. One that's getting a lot of attention is Catalyst.
Invest in a few copies of Perl Best Practices, bring in a proper trainer for a few classes on modern development methods, and start changing the culture of your group.
And if you have trouble finding developers that are already proficient in Perl, you can always hire good PHP people and train them, that shouldn't be too difficult. At least their willingness to learn a new language would be a good sign of their flexibility and will to improve.
It is always tempting to blame the state of your code on the language its written in, but in your case I am not sure that is the case. Lots of big companies seem to have no problem managing huge code bases in Perl, the list is long but the main Web companies are all there, along with a number of financial institutions.
I would bring in someone who is very good at Perl, to at least look at the current design. They would be able to tell you how bad the Perl code really is, and what needs to be done to get it into good shape.
At that point I would start considering my options. If the Perl code is salvageable, well than great, hire someone proficient in Perl. Also train some of your existing staff to help on the existing code-base. If you don't have someone proficient in Perl in charge of the Perl code, your code-base may become even worse than it already is.
Only if it was in terrible shape, would I consider abandoning it for another language. What that language is, that is something your going to have to think about that yourself.
p.s. I'm a bit biased, I prefer Perl
If regex is important I would choose a language with good support.
If you would use java, you will not be able to just copy paste your regex code from the perl code because the slashes have to be escaped. So I would vote against java.
I'm not familiar with php enough to know its regex features, but given your choices I would go for python. You can create cleaner code in python.
Would ruby also be an option? It also has good perl like regex support and rails supports agile web development out of the box.
first off let me point out that MySQL's spatial extensions work with GIS.
Second, if you have a bunch of Perl programmers that will need tow ork on the new sites then your best bet is to choose something they won't have too much trouble understanding. The obvious "something" there is PHP. When I learnt PHP I'd done some Perl years ago and picked up PHP in no time at all.
Switching to something like Java or .Net (or even Ruby on Rails) would be a far more dramatic shift in design.
Plus with Apache servers you already have your environment set up and you can probably stage any development as a mix of Perl and PHP reasonably easily.
As to the last part of your question: what would you do it in if you could do it over again? To me that's a seprate and basically irrelevant question. The fact is you're not rewinding and starting over, you're just... starting over. So legacy support, transition, skills development and all those other issues are far more important than any hypothetical question of what you'd choose in a perfect world if all other things were equal.
Love it or hate it, PHP is popular and is going nowhere anytime soon. Finding skiled people to do it is not too difficult (well, the dificulty is filtering them out from the self-taught cowboy script jockeys who think they can code but can't) and it's not a far step from Web-based Perl.
If your developers are any good, they'll be able to handle anything thrown at them. Deciding what language to use is quite a tricky strategic position, but I recommend you think very carefully before introducing any MORE (i.e. don't).
Unless of course, there is something that you absolutely cannot do (or cannot do sanely) with what you've got.
I think choosing a single language is key and if your database is primarily MySQL, then PHP seems like the obvious choice. It naturally works with your database, it's open source and there is tons of documentation, source code, doesn't require compiling, etc.
People come and go through positions and any website will evolve over time. If you have the ability to set some guidelines and rules, I would choose something that is forgiving, common-place, and easy(er) to learn.
I'd also suggest writing it down so people in the future don't re-invent the wheel.