How to set up relationships between these models? - ruby-on-rails-3

Please forgive the title, I don't really know how to phrase this problem. Essentially I have an Elo rating system - like facemash - that has Users and Players. The Users vote on which Player is the best out of two. I would like to build a third model, Vote, which stores the User who cast the vote, and the winning and losing Players.
How would the vote.rb and the db/migrate files look in order to achieve this? I'm fairly new to Rails, this is my first app, and I've not used any relational stuff yet. I'm using Rails 3.

I ran into this same question on an app I was working on a few months ago, and I discovered that there are many voting gems available. I really recommend against trying to re-invent the wheel, especially when there are gems out there that will do this and more for you. :)
I've tried most of them but the one I liked the most is thumbs_up. It's got a lot of really cool features I think it should do exactly what you want it to do.
Hope this helps!

Related

Good review but 1 star on Play Store/App Store. How can I solve this problem?

I have a problem as stated in the title. Sometimes in the Play Store, users make comments saying that they like our application. (Good, super, I like it) But they give 1 star either intentionally or accidentally. I tried to give them all kinds of answers. I offered a free trial to fix the comment. I said, 'I think you gave the wrong star, please correct it'. I made such comments, but no one corrected it. Users who make such comments are usually from the same country. 3-4 similar countries.
What do those of you who encounter this problem do? Any suggestion?
Thank you. Healthy days.
I noticed the same exact thing from Countries that have languages that are written Right-to-Left.
I think this is a user experience problem in Google play with these languages, if the user quickly adds the review then it he/she could accidently put 1 start instead of 5 stars.
Unfortunately you can not do anything about it.

Distributed rendering in a CAVE system

I am currently working with CAVE systems and I'm looking into hooking up a pre-exisiting game engine in one. I know this is possible through Unity and the Unreal Engine as there is already research out there showcasing that it has been done.
Right now, I have not decided upon one game engine to use and I'm currently looking around and researching if it is possible with the likes of CryEngine and Valve's Source Engine. The one issue that I am going to face, however, is getting the image to correctly render across all four of the monitors / screens.
Thusly, as a result I have two questions:
1.Does anyone know of any good research / books on distrubuted rendering? It doesn't need to be specificly for games, just the topic in general would be very useful
2.Does anyone know if other developers have managed to get Source and the CryEngine to run in a CAVE system? Through all my research I haven't been able to find anything on this, but then my google skills aren't the greatest.
If anyone could spare the time to answer these questions, I'd be extremely greatful.
Thanks.
too late for an answer, but still, you might want to have a look at
Equalizer: http://www.equalizergraphics.com
IceT: http://icet.sandia.gov
Chromium
(and a few more referenced in related publications, websites)

Architectural Description Language (ADLs) usage?

Im doing a project for Software Architecture Module and have to create one of my 'Views' using an ADL. While I've been doing some research into the various ADL's I have found out that most of them have not been updated within the last 5 years......they call seem to be dead.
Are ADL's used in the industry or is it just UML? Cause im getting the feeling that im being taught something thats not useful :s
Thanks in advance
First of all, I've never heard of ADL.
Secondly, every technology that you use in school will be outdated by the time you graduate and get into the industry. But that's not the point. The concepts are the same, regardless of the technology. A variety of experience is the most important thing, because that will give you a large well of concepts to draw from and apply.
I hope to be using different technologies in two-or-three years than what I am using now. That is the great thing about this profession. It doesn't stagnate.
Thirdly, in a few years you are really going to regret always going by the handle "ADLNoob" in online fora. ;-)

How do i identify improvement areas for software development in my team?

i just joined this new group and basically haven't even really done any heavy lifting development but just some basic web store migration stuff. and i've been given the challenge of coming up with improvement areas for the development process. I'm thinking of using Joel's list as the basis for determining what can be improved in my team, and besides that perhaps ask few of my seniors there who have been around for a while.
i'm not exactly sure why i was given this but i'll take it on anyway as it sounds like a good challenge. but what other tips or resources that you would advice me on how to do this properly.
P.S: i have about two weeks to do this, thus please suggest something practical and nothing to big as it's just lil ol me who has to do this within this time frame. :)
thanks
Having been in this tricky position a few times let me give you one piece of candid advice.
The person who gave you this task almost certainly has an idea in mind, and they would like you to reinforce that idea.
How you react to this is up to you and the environment in which you work.
I think you'll probably have to start by finding out where the major weaknesses are. Given your time-frame, you'll have to focus on the a few of the major issues.
Try and find out where time is being wasted. Interview your colleagues, customers, etc to try and find out where the pain is being felt. Observe the team at work and try to identify areas of inefficiency.
You'll probably find people are more receptive to your recommendations if you focus on the immediate problems, as opposed to coming at them with a range of good practices.
Once you've identified a few problem areas you'll be able to research some possible solutions in depth. Without a tighter focus, you'll be swamped by the different possibilities. And, in practice, you'll probably need to introduce new initiatives gradually anyway, which will involve you reviewing the next steps incrementally.
In order to decide what to improve you have to take into account the current status (obviously). Try to find "pain points" - the things that cause grief to the developer's while doing their job:
Do they have proper tools?
Are they fully aware of the current development goals?
Do they have an optimal development environment?
Are you using Agile/TDD/Pair programming?
I've choose the points above because they can be fixed easily in two weeks.
You've been working in this company for enough time to come up with several points of improvement, also talk to the other developers to find out what they think could improve their work.
Whatever you decide remember that your goal is to improve the development process for the dev team but also for the end customer - think on how you can provide high quality software in less time (within budget).
Since most humans come with a brain, teams usually already know what the problems are and how they can be solved. Only, there is a reason why the situation is like it is and there are forces which actively prevent change.
So just ask them what needs to be done and then find out a way how you can either do it or talk them out of it.

Quick and Dirty Usability testing tips?

What are your best usability testing tips?
I need quick & cheap.
While aimed at web design, Steve Krug's excellent "Don't Make Me Think: A Common Sense Approach To Web Usability" features (in the second edition, at least), a great chapter entitled "Usability Testing On 10 Cents A Day", which I think is applicable to a much wider range of platforms.
The chapter specifically deals with usability testing done quick and dirty, in a low-budget (no money and/or no time) environment, and illustrates some of the most important considerations for getting an initial "feel" of the thing.
Some of the points I like in particular are:
You don't need to test with a huge number of people (a sentiment also echoed by Jakob Nielsen)
A live reaction is worth a lot; if possible, make sure the developers can see the reaction (perhaps using a video camera and a TV; it doesn't need to be an expensive one)
Testing a few people early is better than a lot later
Joel Spolsky is known for advocating "hallway usability testing", where you grab a few passing users and ask them to complete some simple task. Partly inspired by the "a few users yield the bulk of the results" philosophy, it's also relatively convenient and inexpensive, and can be done every so often.
Ask someone non-techy and unfamiliar with it to use it.
The archetypal non-technical user, one's elderly and scatterbrained maiden aunt. Invoked in discussions of usability for people who are not hackers and geeks; one sees references to the “Aunt Tillie test”.
The Aunt Tilly Test (Probably needs a better name in today's day and age, but that's what it's referred to)
You have to watch people use your application. If you work in a reasonable sized company, do some 'hallway testing'. Pull someone who is walking past your door into the room and say something like, 'Could you please run the payroll on this system for the next month? It should only take two minutes'.
Hopefully they won't have any problems and it shouldn't be too much of an imposition on the people walking past. Fix up any hiccups or smooth over any processes that are unnecessarily complex and repeat. A lot.
Also, make sure you know what usability is and how to achieve it. If you haven't already, check out The Design of Everyday Things.
Some good tips here.
One mistake I made earlier on in my career was turning the usability test into a teaching exercise. I'd spend a fair amount of time explaining how to use the app rather than letting the user figure that out. It taught me a lot about whether my applications were easy or hard to use by how puzzled they got trying to use the app.
One thing I did was put together a very simple scenario of what I wanted the user to do and then let them go do it. It didn't have step-by-step instruction ("click the A button, then click the B button") but instead it said things like "create a new account" and "make a deposit". From that, the user got to 'explore' my application and I got to see how easy it was to use.
Anyhow, that was pretty cheap and quite enlightening to me.
Quick and cheap won't cut it. You have to invest in a user experience framework, starting with defining clear goals for your app or website. I know it's not what people want to hear, but after supervising and watching a lot of user testing over the years, using Nielsen's discount usability methods is just not enough in most cases. Sure, if your design really sucks and have made huge usability errors, quick and dirty will get 80% of the crud out of the system. But, if you want long-term, quality usability and user experience, you must start with a good design team. And I don't mean good graphic designers, but good Information Architects, interaction designers, XHTML/CSS coders, and even Web Analytics specialists who will make sure your site/app is measurable with clear goals and metrics. I know, it's a lot of $$$, but if you are serious with your business (as I am sure most of us are), we need to get real and invest upfront instead of trying to figure out what went wrong once the whole thing is online.
Another topic to research is Heuristics for usability. This can give you general tips to follow. Here's another use of heuristics
If you don't know where to begin, start small. Sit a friend down at your computer. Explain that you want them to accomplish a task using software, and watch everything they do.
It helps to remain silent while they are actually working. Write everything down. "John spent 15 seconds looking at the screen before acting. He moused over the top nav to see if it contained popup menus. He first clicked "About Us" even though it wasn't central to his task." Etc.
Then use the knowledge you gain from this to help you design more elaborate tests. Tests with different users from different knowledge realms. More elaborate tasks and more of them.
Film them. A web-cam mounted on the monitor is a good way to capture where their eyes are moving. A video recorder coming over their shoulder at 45 degrees is a good way to capture an overview. Bonus points if you can time-sync the two. Don't worry if you can't do it all. Do what you can do.
Don't plan your test as if it's the last one you'll ever need and you want to get it perfect. There is no perfect. The only thing approaching perfection is many iteration and much repetition. You can only approach 100% confidence as the number of tests approaches the number of actual users of your software. Usually nobody even gets close to this number, but everybody should be trying to.
And don't forget to re-test people after you incorporated the improvement you saw were needed. Same people, different people, either is ok.
Do what you can do. Don't lament what you can't do. Only lament what you could have tested but didn't.
I am answering very late but I was thinking about asking a similar questions about some ideas. Maybe it is better to keep everything in this question.
I would say that:
Do not teach people about your app. Let them have fresh eyes.
Ask them to make some tasks and record their actions with a tool like camstudio http://camstudio.org/
After the test, ask them to answer so simple questions. Here is my list:
What was your first feeling when you accessed the app?
Can you define the key concepts that are used by the app?
What are the top-3 positive things about the application?
What are the top-3 negative things about the application?
What do you think about these ideas?