I need to use an ORM for my project and I opted to use ROM, since every other ORM seems to be directly tied to Rails and I am not using and will not use Rails.
I find the official documentation of ROM, found on www.rom-rb.org, to be awful. It doesn't provide any minimal code examples or even a cohesive experience. Instead, it gives you multitudes of theoretical breadcrumbs that are completely unrelated to each other. After reading the entire documentation under the "Learn" section, I realised my knowledge of ROM did not change in the slightest.
I need help from developers who have experience with ROM. Is there an actual source of knowledge on how to use ROM? Where can I find code examples or projects that use ROM? Or is there a good alternative ORM in Ruby that isn't tied to Rails?
Following some recommendations from the comments to the question, I decided to ditch ROM in favour of Sequel. It really turned out to be much simpler and, most importantly, to actually work.
It is quite ironic that ROM is in part based on Sequel...
Related
I am looking from a security perspective and are there any frameworks available to build and use JSON?
I am interested because of the performance which C++ can offer. Currently, Python and Node.js are also available option for me. How can I decide which language+framework should I use ?
Appreciate your support.
Thanks !
PS. - Currently, I am using Java Spring to implement restful apis.
There's plenty of them out there. The absolute simplest one I found, and use, is this. https://github.com/eidheim/Simple-Web-Server .
There are clearly more sophisticated ones out there, just "ask the google". I don't know of any exhaustive comparisons between these frameworks and the ones you specified. However, you could write your own simple benchmarks around the domain you're most interested in. That's what really matters, right?
For json libs there's rapidjson and spirit json. Don't waste your time with boost::property_tree, it's not fully fleshed out wrt JSON.
As for speed. It's compiled so.... its a good possibility that a C++ framework will outperform one based on an interpreted language. So lets say it's faster, you have a heck of a learning curve to climb (assuming you don't know C++ already) but in the end, in my humble opinion it's worth it. I've done these before in Python and Ruby. I really enjoy having the compiler check types. My code is more robust, it does what I tell it to do, and I'm not forced to use exceptions.
Tip: get a code completion plugin like YouCompleteMe
I need to create a custom GUI framework for a project. I actually created a very primitive GUI framework which has buttons, images, text etc. But it is pretty simple and I don't have any prior knowledge of designing a GUI framework. The project we are working on got a little serious and I need to do a better job. So, what books or any kind of documentation can you recommend for me?
Note: I want to create the framework probably in an object-oriented way and I will probably use C# but the documentation does not need to be in C#.
Ok, I'm far from an expert but I'll try to write some useful stuff. I don't know much about your experience, so sorry if it seems silly.
I have been working with several GUI frameworks in the past, in various languages (wxpython, gtk+, swing, . . .).
Never as an expert, but here is what I can say :
Keep it simple. If you want to design from scratch, I guess there is no need for crazy complex stuff. Try to keep it as straightforward as possible by reducing the number of inputs and options in your elements.
b. A major common point of all the successful frameworks I know is the abstraction. Each single element can be easily handled, but it still has the power of all its parents.
This allows your objects to be really versatile while simple.
Read lots of other frameworks documentation. I like spending time reading the doc of GUI framework because it helps you understand the abstraction levels. I find the pygtk doc easy to read.
Use other frameworks. Most frameworks do things more or less in the same way. This is especially true for GUI frameworks. Frame containing layouts; menubars and statusbars; I bet 95% of the concepts you want to use can be found in the other frameworks.
In this way, the best way to know how to develop it is to know what you need and how to do it.
Whenever I work on a GUI, I start reading the corresponding series of articles here .
The writer does a great job explaining everything in a simple way, so that you can get along fast with the concepts.
Keep it open. Something I see more and more often is the use of high level syntax for describing GUIS. GTk for example can take XML files in input and create a whole interface out of it. I find it very nice for abstraction, and reuse. And I also greatly reduce the amount of code needed.
I couldn't really find books on the precise subject you want. I think you already searched on the web also.
I hope those small ideas will help you.
I've been reading up on several PHP frameworks, and reduced my candidates to CodeIgniter and Symfony (I know there are many more). Strongly leaning towards CodeIgniter, but have not 100% decided quite yet.
I'm not looking for a general "CodeIgniter vs Symfony" discussion.
One thing keeps coming up in comparisons: people say Symfony is for "advanced" coders and "bigger" sites; CodeIgniter is for "beginner" coders and "smaller" sites. But I have yet to see any technical proof of this. Everything I'm seeing about CodeIgniter feels right.
Can anyone explain structurally and technically where people are basing these statements on?
I want to understand all I can. Once I make a decision, I want to focus my attention on one framework.
Thanks,
Matthew
The biggest technical difference between CodeIgniter and Symfony (ver 1 and 2) is that Symfony is much easier to extend. This is especially true with Symfony2; you can replace entire parts of the framework as you see fit with custom code, or code from other libraries. You can even take any number of core components from Symfony2, and build your own framework on top of it. But, it's important to note that because Symfony is so 'advanced', it has a higher learning curve.
Here's how I see it: CodeIgniter is great when you have a small(ish) project that falls in the category of problems CodeIgniter is meant to solve. But when you want to do something your way, not CodeIgniter's way, you're going to have to fight the framework, which is never fun.
On the other hand if you're working on a Symfony2 project and want to do something your way, you can. It won't necessarily be quick, but it is possible. To me, that's the most important thing - you need to be able to make the framework do what you want it to do.
If you have time, read through the Symfony docs and cookbook - they should give you an idea of what Symfony is capable of and how to customize and extend it.
Everything I'm seeing about CodeIgniter feels right.
Then go with CodeIgniter. The most important thing is that you're comfortable with the framework/toolset. If you complete a project and find that it's lacking in features, you can always check out other frameworks.
I would recommend starting without a framework. If you have been programming awhile and are comfortable with concepts like MVC and why you might implement your code in this pattern, then frameworks start to make more sense.
Frameworks are good for larger projects where there are many programmers and you need a consistent method of building application layers, like MVC. The framework will likely provide some mechanism for object management and a consistent way for you to build application events (controller) and to separate the view logic from the model logic.
My PHP apps have been smaller, so I have not used any frameworks. When I used to code in Coldfusion, on larger apps, I used MachII, Model-glue, Fusebox and ColdBox. Each was good at something, each promoted consistency, but each had a lot of overhead and often times felt like it was in the way. I saw some developers get stuck because of the framework.
I did not start using any CF frameworks until I had build smaller apps without one.
If you like CodeIgniter better, for whatever your reasons, go with it.
CodeIgniter, because of the gentle learning curve and the great documentation. Give other frameworks a go if you ever feel you outgrow CI, which you may never do.
I'm looking for a simple Ruby framework for a non-web project. I'm very familiar with Rails, so when I write pure Ruby I miss:
The different environments (development, test, production)
The console rails c
And many other utilities provided by rake or rails
I know I can require ActiveSupport and friends, but it's not what I need. It's mostly the development framework that I miss.
One thing I investigated is to do my project as a gem (even if I don't need a gem at the end). Using jeweler for instance provides versioning. I'm sure there are better ways but I can't find any. What would you use ?
Alright, that is somewhat of a three-part question. A threstion, or triesti... actually that doesn't work. Threstion it is then.
One thing to understand about Rails is that it isn't magical. It's code, written by mortal humans who have faults (such as oversized-egos) but who are also incredibly damn smart. Therefore, we can understand it after perhaps a little bit of studying their work.
1. Rails environments are lovely
The code behind the Rails environment management is actually quite simple. You have a default environment which is set to development by this line in railties/lib/rails/commands/server.rb. You could do much the same thing in your application. Run a bit of initialization code that defines YourAwesomeThing.environment = ENV["AWESOME_ENV"] || "development". Then it's a matter of requiring config/environments/#{YourAwesomeThing.environment}.rb where you need it. Then it's a matter of having configuration in those files that modify how your library works depending on the environment.
I couldn't find the line that does that in 3-1-stable (it's gone walkies), so here's one that I think does it in the 3-0-stable branch..
As for the lovely methods such as Rails.env.production?, they are provided by the ActiveSupport::StringInquirer class.
2. Rails console is the Second Coming
I think rails console is amazing. I don't want to create a new file just to manually test some code like I would have done back in the Black Days of PHP. I can jump into the console and try it out there and then type exit when I'm done. Amazing. I think Rails developers don't appreciate the console nearly enough.
Anyway, this is just an irb session that has the Rails environment loaded before it! I'll restate it again: Rails is not magical. If you typed irb and then inside that irb session typed require 'config/environment' you would get (at least as far as I am aware...) an identical thing to the Rails console!
This is due to the magic that goes on in the initialization part of Rails which is almost magic, but not and I've explained it in the Initialization Guide Which Will Be Finished And Updated For Rails 3.1 Real Soon I Promise Cross My Heart And Hope to Die If Only I Had The Time!
You could probably learn a lot by reading that text seemingly of a similar length to a book written by George R. R. Martin or Robert Jordan. I definitely learned a lot writing it!
3. The Others
This is where I falter. What other utilities do you need from Rake / Rails? It's all there, you just need to pick out the parts you need which is actually quite simple... but I can't tell you how to do that unless you go ahead and paint those targets.
Anyway, this is the kind of question that is exciting for me to answer. Thanks for giving me that bit of entertainment :)
Edit
I just noticed the BONUS fourth question at the end of your question. What would be the point of versioning your project? Why not use a version control system such as Git to do this and just git tag versions as you see fit? I think that would make the most sense.
First of all, Rails goal as a web framework is to let you mostly forget about the low-level details of a web based application (interacting with a web server, a database, etc.) and provide you with high-level abstractions which allow you to concentrate yourself on the actual job: Getting your application done.
There is such a huge diversity of non-web applications, that it is simply impossible to have a framework that "makes them all".
It is useful to understand what a framework is, and why and when you should use it.
Let's say you would have to build a dog house. You would buy some wood, nails and a hammer to build it the way you want from scratch, or you could go to Walmart and buy a DIY doghouse kit.
You will get a manual with detailed instructions on how to build your dog's "dream doghouse", and you will get it faster done than when making it from scratch, but you will be limited to the wood that comes with it and may be forced to use their nails or screws, and in some cases you would also need to buy a special screw driver.
The DIY kit is your framework. Some smart guys already provided you with the basic tools of making your doghouse, you only had to figure out (or not, if you had a manual) how to do it given their "framework".
Now, let's say you would build a skyscraper. The materials, tools and conventions (the framework) used would probably not be the same as they would when building a doghouse, and it would be over-kill to use a "skyscraper framework" to build a doghouse.
You wouldn't write Twitter client with the same set of tools and conventions as you would when writing a banking application with a billion concurrent users.
Rails is just one framework which provides you with a set of many, many good (and useful) conventions to write a web application, but that doesn't necessarily mean that it's the ultimate way to go. You can choose another framework, and maybe you will like the conventions for writing your application even more than the ones provided by Rails; or you could write all from scratch which would not limit you to what is provided by a specific framework and maybe make it even better.
To answer your question: Think of what you want to write and don't let yourself be narrowed down by the set of tools and conventions provided by a framework, as they will surely be if you choose this path.
Buy yourself some books about Design Patterns and read some great software, and then you may understand why the authors did not choose an application framework. Indeed, they've developed their own conventions and defined the behavior of what it should do; and once again, the "Rails way" isn't the only way, which doesn't make it the bad way. :)
I would appreciate constructive criticism as I really tried to provide a good answer.
Have you looked at Monkeybars? It's a Rails-inspired MVC framework that runs on top of JRuby and Swing to build desktop applications. I like it a lot.
I am looking into developing a commercial application using PHP. Since I have experience in CodeIgniter and it has been working well for me, I decided to use it. Now, if ever my application comes to a point that it needs to grow and have to have custom modifications in the platform, is it possible to modify the CodeIgniter source code to the point that it's far from the original?
I'd strongly recommend not modifying the source code as this is the back bone of the application will make updating to futures releases of codeigniter impossible.
Instead you should be creating your own classes/libraries that extend the core bases. This is best practice.
The codeigniter users guide has some fantastic information regarding this, http://codeigniter.com/user_guide/general/creating_libraries.html
Good luck.
Don't modify it, extend it. Ellislab is good about releasing bug fixes and patches, and the last thing you want is to have to re-engineer all the updates into your new hybrid everytime they release updated source code. Plus, different features and bug fixes are released at different paces for the core and reactor, so unless you plan to lock your framework in at the current version, extending is the way to go.
The good news is CI is built for and encourages extensions of the source. The system folder and the application folder separation are a clear indication of how you should segregate your enhancements from the base libraries.
CodeIgniter is written in PHP. You can completely rewrite the framework anyway you like. So the answer is "yes".
There are many big websites that were written in a different language or build on a framework when they started and have been rewritten many times since. I think a lot of developers (mostly freelancers) are over-thinking when starting out. When I start a project, then I try to get it done and get it out in the web asap. If a website starts taking of - and most of the times start making you money - then you can always take the time to rewrite it.
I think it is a lot more important to spend time when you plan and design your database and tables. I think it is a lot harder to redo parts of your database later on then it is to rewrite the code that uses the data.
Just my 2 cents.
If you have used CI, then you should know that being a PHP framework that all of the source-code is there in the download, furthermore opening the system and application folders and looking through there will tell you a lot. Yes all of the source is there in plain English (plain programming English) and not only is it in plain English but has been extensively documented inside and out (literally that is in the source and in the user-guide). CI gained initial fame from that simple fact, that all code is extensively and meticulously documented.
Beyond all that, the question itself raises concerns that maybe you should study CI a bit further before writing commercial applications using it. Ci is a powerful and very easy to use PHP framework, but it is not a WYSIWYG. In my opinion, a coder should know his tools inside and out in order to be able to create a solid secure and trusted application. The first measure of which is to read the user manual, you should know at the very least everything in it, and since there are 12 sections in it that cover everything from extending CI libraries to creating your own libraries, and everything in between I would say you need to spend a little more time with it.
I want to say though, I am not being rude or trying to shame you in any way I am simply saying that you should learn the framework a bit more before venturing into a commercial application using it.
In the early days of PHP people realized how amazingly easy it was to use and how fast you could write an application with it. At the time the major options where very difficult for new and hobby programmers to use or involved expensive software to run, PHP was free, easy to learn and most of all ran on a free OS. It also took hardly any setup to get going, you could download PHP and essentially be programming in minutes. All of these factors lead to the almost destruction of the language.
Entry level programmers were destroying it with bits of code taken from other applications, never knowing (or caring) what the code actually did beyond the simple fact that it did what they wanted at the time, never considering or even investigating if the code might be harmful. Because of this practice PHP applications that had grown to Goliath sized websites, taking thousands of hits an hour were:
beginning to crash
being hacked to reveal sensitive customer/client data
generally crumbling all around the web
All because since the language was so easy to use that people had taken advantage of it and failed to take time to learn it. PHP was becoming a joke to other professional programmers and wasn't even thought of as a viable application language by many who had dubbed it "the copy and paste" language.
So my advice to you, please take the time to know your tools inside and out, what makes them tick, if they have any gotchas and where they are vulnerable. I understand that in order to learn a language to a professional level you have to build with it so I suggest that you take it slow with CI stick to the core for now. Trust me when I say that even in its purest form CI is an amazing and powerful tool that in the right hands can create awesome powerful web application, but in the uneducated/inexperienced hands it can create havoc and destruction.
So (stepping off of the soap box) I simply ask that if you are serious about creating commercial applications period that you take your time and learn your tools/language become as close to an expert on them as possible. I gurentee that if you do that you will always have work when you need it and you will spend less hours beating your head against the table or worse explaining to a client why their site is down.
I truly wish you good luck, just slow down and learn your trade and you will do just fine.
Yes, Codeigniter is an open source framework. However, I would advise against modifying the core of Codeigniter, as most files can be extended and rewritten safely without modifying the core files which will cause you headaches if you ever decide to update.
To extend a core class by default you would do this in Codeigniter. We'll extended the parser class for this example, but this applies to all classes pretty much. This link in the comprehensive user guide will give you all the information you need to extended and overload methods inside of a Codeigniter core class: http://codeigniter.com/user_guide/general/core_classes.html