We show feedback on our application, but we want to show only 10% of users only.
For Ex: if total users are 1000 and feedback should be shown only to 100 users.
Is there any idea an logic to implement it?
Thanks in advance
Try using the random method:
if(Math.random()<0.1) {
// show feedback
}
In you database you can have query like
SELECT TOP X PERCENT select list
FROM TableName
And this way you can fetch only 10% of records from DB and show them on the feedback module.
Hope this is what you looking for.
A pattern I have found useful before is to "label" some users at the start of the session (randomly according to your required distribution). Then record in detail everything the labelled users do with your application. Any feedback they give can then be put in context. As for the mechanism, I would go with a Filter for the initial session labelling and then show an unobtrusive bar at the top of the screen for the labelled users which prompts them (nicely) to give feedback. Make sure the bar has a close button.
This code generates a random number from 0 to 9 and if the randomnumber is 0 (10% chance), then, you can add the feedback code.
var randomnumber=Math.floor(Math.random()*10)
if (randomnumber == 0)
{
// do something
}
If you really, really need it to be EXACTLY 10%, rather than approximately 10%, you could keep a static counter variable that you increment every time a new session starts. When it hits 10, ask the user for feedback and reset the counter to 1.
However, you'll likely need to synchronize access to the variable to prevent requests on different threads manipulating it at once, and this might be a performance bottleneck if you are processing a lot of requests.
Unless you have a good reason, it's probably a lot easier to go with the random number method others suggested.
I think you need to think this through - down the road, you might wish that you did something more than just "display to 10% randomly".
If you are talking about an application that uses authenticated users, and if there is any potential need at all to analyze/understand the response of that 10%, then you ought to do the following:
Create a new column or table in your database which assigns each user to either be in (true) or out (false) for your feedback display
Use that as the basis for your query to determine to whom you show the message
Make sure that the result of that feedback request written back to your database.
Related
So I have a program that runs on multiple computers. The program connects to a server where it gets all of its data from. There's a JPanel which lists names from a table in my postgresql database. As of now, the only way to refresh the panel is with a button press. I want the panel to update on its own when there is a change in the database so if one user adds a name, the other users will be able to see the change right away. Is there a way to broadcast a message to all users that are connected to the server so that their panel can refresh?
As soon as you want to do something like this you enter the world of multiple threads and all kinds of havock. Your question does not really have anything to do with databases, you merely want to send a message to all others using the application to update a component when they need to, keep your concerns separate. Now then you need to ask some questions like are the users all on the same network? Then you can get away with a simple chat client for java, there are heaps of them out there. But think about it, do you really need this requirement? Can't you just update the table say every 10 seconds? Or every 5 seconds? The difference in the difficulty of the implementation is substantial but the result I would say would be very similiar, unnoticable to the user even. But maybe you just want to learn stuff, then maybe you think you should add another table in sql with one entry which records the time the user table was updated which you can check and will be more optimal than the other. But this is considered bad practice, do you care? Same with sql statements to check when a table was edited last from what I have seen on the net, but should we always apply best practices, the application will still get across the line.
Maybe your update button is not looking so bad after all.
But users complain about that sort of crap and you can't explain this stuff to every user. My suggestion would be to have a configurable update that runs every how ever many seconds you tell it to. You will have to look up stuff about multi-threading though but shouldn't be too horrible.
I'm programming an app that will display the result of a team. I'd like notify the user when there's a goal. To do this, I created a service where I'll take the score and put it in a String every 30 seconds and I'll create a notification if it changes. My question is: What's the best way to repeat this every 30 seconds ?
Thank's and sorry for my poor english
Well if you want to do a call every x seconds that would require an ajax setTimeout (not setInterval). If you are going to do that it would be a good idea to send back some data to the db each round trip to make sure your query is not massive, and searching the entire db table.
For example you might send back the most recent timestamp on each round trip. And then have the backend query check how many rows are greater then that timestamp and display the count to the user. So if there is one row, show the user 1 new row. And when they click it query for the content. This should be a low impact query for a high impact activity (pooling would be a better option). Goodluck.
PS: If you want to get fancy and really learn some stuff tonight I would do some research on asynchronous servlets, rather then just pooling as another poster advised. That would lead you down the rabbit hole to some really sweet stuff.
You can do something like :
check if anything changed (yes - send new info, no - do nothing)
sleep 30 sec (Thread.sleep(30000))
repeat
I have a database full of two different types of users (Mentors and Mentees), whereby I want the second group (Mentees) to be able to "search" for people in the first group (Mentors) who match their profile. Mentors and Mentees can both go in and change items in their profile at any point in time.
Currently, I am using Apache Mahout for the user matching (recommender.mostSimilarIDs()). The problem I'm running into is that I have to reload the user data every single time anyone searches. By itself, this doesn't take that long, but when Mahout processes the data it seems to take a very long time (14 minutes for 3000 Mentors and 3000 Mentees). After processing, matching takes mere seconds. I also get the same INFO message over and over again while it's processing ("Processed 2248 users"), while looking at the code shows that the message should only be outputted every 10000 users.
I'm using the GenericUserBasedRecommender and the GenericDataModel, along with the NearestNUserNeighborhood, AveragingPreferenceInferrer and PearsonCorrelationSimilarity. I load mentors from the database, add the mentee to the list of POJOs and convert them to a FastByIDMap to give to the DataModel.
Is there a better way to be doing this? The product owner needs the data to be current for every search.
(I'm the author.)
You shouldn't need to ask it to reload the data every time, why's that?
14 minutes sounds way, way too long to load such a small amount of data too, something's wrong. You might follow up with more info at user#mahout.apache.org.
You are seeing log messages from a DataModel, which you can disable in your logging system of choice. It prints one final count. This is nothing to worry about.
I would advise you against using a PreferenceInferrer unless you absolutely know you want it. Do you actually have ratings here? I might suggest LogLikelihoodSimilarity if not.
I've been going round in circles with what must be a very simple challenge but I want to do it the most efficient way from the start. So, I've watched Brett Slatkin's Google IO videos (2008 & 2009) about building scalable apps including http://www.youtube.com/watch?v=AgaL6NGpkB8 and read the docs but as a n00b, I'm still not sure.
I'm trying to build an app on GAEJ similar to the original 'hotornot' where a user is presented with an item which they rate. Once they rate it, they are presented with another one which they haven't seen before.
My question is this; is it most efficient to do a query up front to grab x items (say 100) and put them in a list (stored in memcache?) or is it better to simply make a query for a new item after each rating.
To keep track of the items a user has seen, I'm planning to keep those items' keys in a list property of the user's entity. Does that sound sensible?
I've really got myself confused about this so any help would be much appreciated.
I would personally do something like:
When a user logs in, create a list of 100 random IDs that they have not seen. Then as they click to the next item, do a query to the datastore and pull back the one at the front of the list.
If this ends up too slow you can try to cache, but it is really hard to memcache you entire database. Even loading the 100 guys they need will be hard (as the number of users scale out). Pulling back 1 entry for 1 webpage load is not slow. Each click will be post 1 comment and pull 1 item back. Simple, only a few MS from the datastore. Doing the 100 random IDs they haven't seen can be slow, so that makes sense to do ahead of time and keep around (in their request or session depending on how you are doing that...)
I want to implement an efficient mechanism to throttle login attemps in my Java web application, to prevent brute-force attacks on user accounts.
Jeff explained the why, but not the how.
Simon Willison showed an implementation in Python for Django:
That doesn't really help me along as I can't use memcached nor Django.
Porting his ideas from scratch doesn't seem like a great either - I don't want to reinvent the wheel.
I found one Java implementation, though it seems rather naiive: Instead of a LRU cache, it just clears all entries after 15 minutes.
EHCache could be an alternative for memcached, but I don't have any experience with it and don't really want to intoduce yet another technology if there are better alternatives for this task.
So, whats a good way to implement login throttling in Java?
I think even EHCache is killing a fly with a napalm bomb. The problem is simple and so is the implementation.
I suggest using a servlet filter a the top level so that as little processing as possible is done.
Create a class to store the following:
The number of attempts (count)
The time
Now, the code is simple in a sunchronized block:
if userid not in attemptMap:
attemptMap.add ( userid, new attemptItem ( userid, 1, now ) )
else
tmp = attemptMap.get ( userid )
if (acquire lock for tmp) :
if tmp.time + 30 > now :
tmp.count = 0
tmp.time = now
tmp.count++
if tmp.count > 3 :
error=true
release lock for tmp
else : error=true
thats it man (as long as the code is synchronized).
I've just completed the web security course run by aspect security and one of the suggestions that came out of that was to just include a natural delay in any login attempt - the theory being that a 1 or 2 second delay is nothing to a real-user but will seriously hamper brute force attacks.
One that hasn't been mentioned is make them answer forgotten password question(s) after so many bad attempts + enter their password
I've used a Login Attempt count field with user details. When it gets to 50, correct passwords are rejected and the user has to perform a password reset.
What about an exponential increase in time between login attemps?
EHCache is pretty good, and more importantly Not Written By You, so you don't have to reimplement features and possibly get them wrong.
My solution would involve either EHCache or something simpler (if it was a small app and I didn't really care about concurrency performance) in the login code.
You would store, per IP, a fail count and a timestamp.
Each time you make a login attempt, workout whether they are allowed to using the fail count and the timestamp.
Each time you make an allowed login attempt and fail, increment the failed count by 1 and record the fail time.
Each time you make an allowed login attempt and succeed clear the info for that IP.
Maintain wrong login attempt number and if it will reach to N, block the user and ask for captcha or password reset to continue.