Looking at the flattr API pages I see that things have both a flattrs and a flattrs_user_count field, but I'm not sure what the difference between them is, since you can only flattr a thing once.
So, what is the difference between the two fields?
I'm pretty sure you can flattr things multiple times, but only once a month, so the counts could in theory be drifting apart over time especially for things that many people are subscribed to (see shownot.es for example).
Related
With the reconcile service I often come across this problem: the best candidate isn't really correct, the best is the second or the third candidate (ad it has also a better score), like this:
How can I select the correct one in mass? I've got thousand of records, and I'm stumbling across lots of cases like this. I think it should be some way that is not doing it one by one.
For instance something that says "take the best candidate score, no matter what's its position".
Edit: as pintoch says, it could be a bug. In the meantime it's possible to create two numeric facet. One with cell.recon.candidates[1].score and the other with cell.recon.candidates[2].score. Playing with them it's possible to select the score of the third and the second candidates to make sure you get the candidate with the best score. Then it has to be reconciled one by one, but it's just a question of clicking.
I would say that this behaviour is a bug in the first place: the candidates should be sorted by decreasing score. The reconciliation service API does not specify that services should return their candidates with any particular order, but that is probably unintended.
The quickest solution would be to contact the person running the reconciliation service that you are using and ask them to sort the candidates by decreasing score on their side.
This also suggests improvements in OpenRefine itself: OpenRefine could always sort the results of a reconciliation service by decreasing score. I have opened a ticket about this.
More broadly, I agree that the current ways to match candidates based on specific criteria could be improved (but this might require redesigning important parts of the reconciliation system, which will take time).
We're having a bit of a debate between specifying the page number vs. row number, along with rows per page. E.g. to get rows 21-40 it could be either
page=2&rows=20
or
offset=21&limit=20
I know this is a bit of an opinion question, but any standards or best practices out there?
This would really depend on the source and consumer of your data but, for comparison, REST best practices (warning, PDF!) specify offset and limit parameters, as in your second example.
I think the document claims this is simpler if pages may contain different numbers of rows; your mileage may vary.
Obviously both work, but I've seen page more often than not. From a UI perspective, users may not know what offset means.. but they have an expectation from changing the page field. Also, if you use page, you should restrict what values limit should be. The point of pagination is to ensure that the backend doesn't send a ton of data back to the UI, so giving only a few options (or choosing for the user) would achieve that.
I hope stackoverflow is the right part of the trinity to ask this kind of question ...
Google webmaster tools shows the keywords it considers important for my blog (blog.schauderhaft.de). But among the top 20% are all the month names (you know january and so on).
I actually have a two part question about this:
why does google think theses are important keywords?
how do I fix that?
It might have something to do with the whole list of archives in the head of your page: <link rel='archives' title='January 2008' and so on.
Do you think this will actually be a problem? These people don't seem to think so..
We used to have a big problem on one of our client websites with a similar problem country names appearing most important. On some pages we were running multiple forms where one could choose a country. Google was finding this all over the place and thus considered it important.
So if you have month names in archives/in dates of articles it might very well be a possibility. You have to ensure you tag each one properly if its a date you can maybe use the HTML5 code to identify that its a date; otherwise in case of archives what you can do is load this using AJAX; or calculate it using javascript.
In order to drop the counry names we had to use a jQuery trick to insert these dynamically into the page following page load. (so google no longer sees the list as important to our website)
I run an online shop and I wonder what would be more SEO-friendly URL for a product page:
a) domain.com/category-name/product-name OR
b) domain.com/product-name
I already have URL-s for product category pages with format domain.com/category-name.
On one hand I heard (but cannot find proof for) that Google like tree hierarchies in URL (vote for "a"). On the other hand though longer URL could lead to smaller kewyord density, also "product_name" comes as the last URL part so probably the least important (vote for "b"). Maybe both options are equally SEO-effective?
PS. I know about canonical URL's but this is not the case, I don't want/need both URL's formats, just want to choose the best.
In my opinion, category-name/product-name might drive more traffic compared to just product-name. Because former one has the advantage of two keywords, while the later just has one.
But, it may affect the results when user just searches for product-name. Because search engines will prefer the keyword which comes very first in the url. In this case, product-name will defeat category-name/product-name.
So, it depends on the product and category you are going to use. How the users will address the product. simply the product or always with the category name. Just do a little keyword research and decide which one to go with.
In a client case of mine, including both category and product name in the URL rendered much better SEO results. I have no empiric references, though. The keyword density landed on about 9-11 %.
smaller url are better. hard to manage as links grows.
so if you can do domain.com/product-name
nothing beats it. and it looks great on search result.
A sites URL structure should be as simple as possible:
Google Webmaster Central Advice on URL structure
http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=76329
http://googlewebmastercentral.blogspot.com/2008/09/dynamic-urls-vs-static-urls.html
Google does highlight the search terms if they appear in the URL.
In Googles words:
"While static URLs might have a slight advantage in terms of clickthrough rates because users can easily read the urls, the decision to use database-driven websites does not imply a significant disadvantage in terms of indexing and ranking."
As https://stackoverflow.com/users/290503/iamgopal stated. Smaller is better. More important if you use the category and at a later time you decide to put your product in another category you have changed the url. Which is not good even if you redirect.
We actually removed all categories from our url's (8 million products or so) to make re-categorization easier. We haven't noticed a significant drop in ranking after the redirect effect wore off.
I'm making a site like StackOverflow in Rails but I'm not sure if it's necessary for the Votes on a question to be stored in a separate table in the database.
Is there any good reason to separate the data?
Or could I store the Votes as a single sum in a field of the Questions table?
How would you know if a user voted on a question without keeping a votes table? Or like this website that holds you to X votes a day, how would you know how many votes a user made in the day? How would you keep track of how many up and down votes a user has done? I think good design practices pretty much scream for you to normalize the data and keep a votes table, with perhaps keeping a current +/- denormalized field in the question row for easy fetching.
Yes! Think about it from an object perspective. In model driven development (objects first) you would have a container (table) of questions, and a container of votes. Of course you could simply roll them up to an aggregate form. However by doing that you lose a lot of metric detail such as who cast the vote, when, etc. It really depends on if you need the detail or not. Space is cheap so not keeping the detail is usually not a good idea. It is hard to foresee what is needed in the future!
Think about your data in multiple dimensions. There's more going on than the mere number of votes. There's:
Who cast the vote
When they cast the vote
The effect (think like a financial transaction) of the vote on any number of parties
Can you afford to discard this data? Will you ever need it? In Stackoverflow, it must be known whether I voted on something to determine if I can vote; what the vote was, so I can change it; the effect of the vote so it can be rolled back if I change it; etc.
Votes would also need to be able to be applied to both questions and answers, although both questions and answers could be stored in the one table/class called Post or somthing similar since they are the same data with a different title.
Like the last two answers say: keep a separate votes table.
But it would be advisable to create a view that will aggregate votes per user, per question etc. so that you don't need to do a manual query when you need that info.
jrh
Yes, I would go so far as to say that it is vital to help reduce the likelyhood that one person could bias the result by repeatedly voting something up or down.
It actually has very little to do with OOP, and more to do with preventing exploits.
For performance reasons you could use a static vote count in the questions table that gets updated when the vote data for a question changes. I would not though only use a vote count by itself unless you really don't care about results being biased by particular people.