Just an open ended question - I'm using rails 3.0.9. I want to experiment with sorting systems. I'll want to start with a simple upvote/downvote system, and then try out more complex iterations.
However, I would want not to sort simply on upvotes/downvotes but provide a controllable skew for time (so that really interesting posts eventually give way to new ones).
Anyone have any suggestions on where to read about these sorting algorithms either generally or in rails(3)-specific sources?
Thanks everyone!
try meta-where meta-search in this project sorting was talked about using meta-search gem. i hope this helps
Related
With beta4 and latest beta5 the DB-Feature-Implementation appears to have pretty much finished. There's a couple of tutorials out there how to handle a single Database using the TableGateway Pattern, but it appears there is none for handling M-N-Relationships.
In ZF1 we had findDependantRowset() on the TableGateway which was kind of dirty, as this simply was a second Query to the databse which pretty much isn't always neccessary.
In ZF2 i expected there to be a way to have good Joins mapping to specified models, but i can't find anything within the code. Maybe i'm blind, maybe there really isn't anything like this.
Has anyone of you managed to handle joins and models all together in ZF2? If so, please be so kind to instruct me how to do it, hint me to specific points of the documentation or link me some blogpost to one who has done it.
Thanks in advance guys!
The obvious solution if you need a generic solution is to use Doctrine ORM or Propel.
If you want to use Zend\Db, then within your concrete table gateway classes, you should write a specific method that retrieves the correct rows from the linked table. This way you can ensure that the SQL is optimised for the query that you need.
I'm currently looking for the best way to save data in my iPhone application; data that will persist between opening and closing of the application. I've looked into archiving using a NSKeyedArchiver and I have been successful in making it work. However, I've noticed that if I try to save multiple objects, they keep getting overwritten every time I save. (Essentially, the user will be able to create a list of things he/she wants, save the list, create a few more lists, save them all, then be able to go back and select any of those lists to load at a future date.)
I've heard about SQLite, Core Data, or using .plists to store multiple arrays of data that will persist over time. Could someone point me in the best direction to save my data? Thanks!
Core Data is very powerful and easy to use once you get over the initial learning curve. here's a good tutorial to get you started - clicky
As an easy and powerful alternative to CoreData, look into ActiveRecord for Objective-C. https://github.com/aptiva/activerecord
I'd go with NSKeyedArchiver. Sounds like the problem is you're not organizing your graph properly.
You technically have a list of lists, but you're only saving the inner-nested list.
You should be added the list to a "super" list, and then archiving the super-list.
CoreData / SQL seems a bit much from what you described.
Also you can try this framework. It's very simple and easy to use.
It's based on ActiveRecord pattern and allow to use migrations, relationships, validations, and more.
It use sqlite3 only, without CoreData, but you don't need to use raw sql or create tables manually.
Just describe your iActiveRecord and enjoy.
You want to check out this tutorial by Ray Wenderlich on Getting started with CoreData. Its short and goes over the basics of CoreData.
Essentially you only want to look at plists if you have a small amount of data to store. A simple list of settings or preferences. Anything larger than that and it breaks down specifically around performance. There is a great video on iTunesU where the developers at LinkedIn describe their performance metrics between plists and CoreData.
Archiving works, but is going to be a lot of work to store and retrieve your data, as well as put the performance challenge on your back. So I wouldn't go there. I would use CoreData. Its extremely simple to get started with and if you understand the objects in this stack overflow question then you know everything you need to get going.
I having some trouble trying to figure out how to implement a Rails 3 multi-page form with file uploads, where each step is handled by the update/edit actions in the controller.
Ryan Bates provided his wonderful screencast for how to to do multi-step forms using sessions, as well as a brief description on how to accomplish something similar by saving to the database on the initial step and then perform updates on each successive step. I have also read his gist giving a more detailed explanation of some different options on how to create a multi-step form (I am leaning toward option 1).
But I am still quite a bit lost when it comes to the actual implementation of a multi-step form. My goal is to use carrierwave for the file uploads (images), and perhaps workflow by geekq for the state machine to help with with validations at each step.
Just to be clear, I am currently trying to create an entry in the database on the initial step of the wizard, and have each successive page update the model.
Any ideas?
An example or a point in the right direction would be greatly appreciated.
Thanks!
Note: I have read another post where they mention something about a key/value data-store, but that unfortunately is a bit over my head...
Key-Value store or SQL for that matter are very loosely tied to your actual problem. Those are just a different approaches on how your data are actually stored in the backend. Using one way or another doesn't really make a difference in your case.
As for the actual question I think its too general for SO. Multistep forms tend to be very different one from another. There is no "one good way" of doing those.
The reason you are not getting any answers on this is probably because there is no real question asked. What you should do is to try to do actual implementation and post more specific questions when hitting the wall somewhere.
In the end - I believe the multistep forms are not really the best idea when it comes to usability. Of course there are valid reasons to use them in some cases, but you should really think twice if there is a way to avoid those in your case.
One of the problems I had while ago with forms and uploads was the validation (It isn't related to Multi/Single step specifically). Normally when validation fails user would have to re-upload the file. Fortunately in your case this not much of an issue, since Carrierwave handles that automatically.
I need to use Acts As Tree in my Rails3 project (ruby 1.9.2). But, there are lot of forks on github, so I don't know which should I choose, and which is used by other developers?
On Railsplugins.org there are http://www.railsplugins.org/plugins/376-acts-as-tree, but last commit was from March...
I'm using http://rubygems.org/gems/acts_as_tree_rails3. Works great.
I've gone with https://github.com/skyeagle/nested_set on my Rails3 projects. It's hard to say at this point where adoption will take things.
I'd suggest using https://github.com/mceachen/closure_tree if you can add a new table to store the hierarchies and want efficient select and mutate performance.
I am building a faceted search with Lucene.NET, not using Solr. I want to get a list of navigation items within the current query. I just want to make sure I'm pointed in the right direction. I've got an idea in mind that will work, but I'm not sure if it's the right way to do this.
My plan at the moment is to create hiarchry of all available filters, then walk through the list using the technique described here to get a count for each, excluding filters which produce zero results. Does that sound alright, or am I missing something?
yeah. you're missing solr. the math they used behind doing faceted searching is very impressive, there is almost no good reason to not use it. the only exception i can find is if your index is small enough you can roll your own theory behind it, otherwise, its a good idea to stand on their shoulders.
Ok, so I finished my implementation. I did a lot of digging in the Lucene and Solr source code in the process and I'd recommend not using the implementation described in the linked question for several reasons. Not the least of which is that it relies on a depreciated method. It is needlessly clever; just writing your own collector will get you faster code that uses less RAM.