General question about components updating in live time - mongodb

Im curious how this is accomplished. Let's say a platform has a voting system on a webpage. A piece of content can be voted on positive or negative. As a user scrolls through the platform, they can see a live change in the amount of votes each piece of content has.
I figured this would be done one of two ways but I am not sure which is the most accepted one.
A timer to call the server ever x amount of seconds and update the components on a loop.
A socket to connect to the backend every time a user opens said page.
I wont know which is best, but I feel like 2 probably wins considering its a little less repetitive.

Related

Google Adsense revenue slowing

I don't know where to ask this, so I'm going to just ask it here and handle the backlash when ever it comes.
First let me state that I'm familiar with the recent issues relating to Pepsi and YouTube how ever what I am currently unsure of is, does this effect website publishers also, or has my traffic just all around stopped converting?
I'm currently getting around 300,000 impressions per day and my revenue has dropped to as low as 0.19cpc when before it was sitting almost around a dollar for every registered click.
Question basically comes down to, are you guys getting effected by this also? What can I do in the mean time if this is in correlation with the advertisers opting out, because it's getting really hard to manage servers with no revenue.
Yes it seems to have had a drastic impact on my earnings as well, although I'm not doing anywhere close to the impressions you're doing.
My cpc and rpm have hit an all time low and its disastrous. I'm seeing the same cpc as you btw, we're not alone other publishers are complaining about the same issue.
I'm considering dropping a few adsense units till i see some better figures.

What are ways to handle too many database connections?

I have a website that caters to daily fantasy sports players and on days with big slates (i.e. a lot of games), the site gets hammered before the lineups get locked. "Hammered" in my case means 50-100 concurrent users, which I'm sure doesn't sound like a lot, but it seems to kill my database host (Mongolab). During "normal" operations, the max number of open connections I see is less than 500, but during these peak times, there can be upwards of 10,000 open connections!
I think what happens is that users open the site, see that it is not responding quickly enough, and then they proceed to open a bunch more sessions thinking one of them will work. This causes the downward spiral.
Last week I added multi-key indexes which helped quite a bit, and I thought had "solved" the issues. But today the site got hammered and even the new indexes haven't proved to be enough. What else can I do?

How to create a "Nuclear" honeypot to catch form spammers

My current honey pot on my registration form is an entry for phone number which is placed off screen using position: fixed;.
It tricked a standard breed form filler, but doesn't work as well as I though. Also, the spambots immediately responded to changes in the form, meaning that this is automatic, what can I do.
Note: I hate captchs since the make they users solve my problems which is never good.
Build a really smart honeypot
That may seem obvious, but here are a few tricks(Details later):
Think Like a spam bot
Assume that they are able to know what is on screen or behind other elements
have multiple traps.
Time Trap
Honey pot
1. Think like a spam bot:
Start going through your page like a spam bot, You can even write your own which can waist time but is quite fun :).
Most spam bots will crawl through the markup looking for a <form> element. Then they will look at your inputs and fill them in appropriately, which is the catch: how do they know what to fill in. They will prbably look at the Id, class, placeholder, and label. which brings us to our first method
Method #1:
Mis label inputs in your form code. Bascily your username input should have the Id of #Form_Email boom! spam bot fills out form incorrectly. Also hide and mislabel your inputs labels, use divs instead.*
Method #2 starts here
You've probably noticed that if you simply ignore hidden stuff, based on location what is in front of it and even the good old display: none;,visibility: hidden;,opacity: 0; or type='hidden'. This gives us a powerful weapon. I discovered this by accident while testing a time trap. I used a basic form filler to fill the form. On my site(I'm not talking about GiantCowFilms.com), the register form is in a dialog that opens when a user clicks a register button. By default it is hidden. This gave me an idea for
Method #2
Default: form is hidden. Basically, your form is hidden on page load, but is uncovered by some mouse based action(I don't think bots have mouses). If you wan't your form to be visible on page load, add a I identical decoy one which is above the real one in the markup.If the bot fills in and submits it, block its Ip for a few minuets.** For really users, simply when the mouse hovers over the decoy form, switch them around.
2. Assume that they know what your page looks like
Assuming that hiding honeypot with CSS is perfect is a grave mistake. Their are a lot of super smart screen readers like JAWS that could be repurposed for spaming. That is why you have multiple lines of defense.
3. Have multiple traps
Time Traps:
Going back to thinking like a bot, would you wan't to wait on a site instead of attacking others?
Method #3:Create a time trap.
The best way is to print a time in a hidden input when the page loads. when you submit the form, it tells you how long it took. Fill the form as fast as you can. That should be the minimum amount of time to fill your for.Note: encrypt your time stamp so bots cannot change it. If you wan't to get really fancy, measure the WPM of the bot typing. This is done on stack exchange( try copy and pasting then submitting and question/answer). Also if the rate of typing is very consistent, that is a red flag.
Honeypots (Method #4):
Use all of the above at once for best results. Make sure to trick dumb bots as well as smart bots (don't assume the bot is always trying hard.).
Now, in order to spam us, bots will have to have cursors, render the page, wait, type at a variable realist speed. If they make a bot like that, Then I guess it'll be Captcha time :(.
*People using screen readers will trigger or be confused by these defenses, and depending on your country you could get into trouble for discriminating against blind to semi-blind people. Therefor, when a user triggers the bot test, take them to a non loaded form with a disability friendly captcha like reCaptcha.
**People often share Ips and you can chase away valid users.
P.S. Use simple honey pots like you already have. Some bots are just too dumb to get tricked by what we have here.
For years, I've used my own 'form spammer trap' that uses a variety of techniques to block spambots. The most effective is to obscure fields (especially the form's 'action') for a short time period. Since the bot scrapes your form for the fields, and the 'action' page, and uses that info to "CURL" your form data, putting false info in those areas will fool just about all spambots.
After a timeout (JS-based), the obscured values are replaced with their actual values. By the time that happens, the spambot has moved onto another target, and using the bogus values will fail.
I've developed this whole process into a free solution available at my "Form Spammer Trap" site https://www.FormSpammerTrap.com . That site has been around for years, and the contact form there has yet to be successfully 'spam-botted'. (You bots are welcome to try.)
To implement in your site, you add one 'include' and three functions. And you can customize the form with some advanced techniques.
For those that are interested in how a spambot works, and why common 'tricks' such as hidden fields don't work, see here: https://www.securitydawg.com/how-bots-spam-contact-forms/ .
My 'FormSpammerTrap' solution is free (PHP-based), and is available via the Contact form (just check the box to get the free code). No obligations; I don't even save your email address.
But it is quite effective. IMHO.
Added 21 Jun 2020
The "FormSpammerTrap" solution is still around, and has had significant updates over the years. The latest version allows a lot more (and easier) customization of the form, although the basic use only requires one customization entry. The documentation is greatly improved.
And I am working on version 9, which will add even more customization. It should be released in a couple of weeks.
The https://www.FormSpammerTrap.com site has full details of the latest version, how it work, and a link to a blog entry I wrote about how form spammers work (and how they can be blocked).
And it is still free - just fill out the contact form on the site and check the box and get it immediately, with full documentation and samples. It's fully guaranteed or your money back! (well, it is free...)
(And thanks for the upvote. )
Added July 2022
The program is now up to version 15, with version 16 in the works. There are tons of new features, but the process still works - it blocks all bot attempts on a contact form. Take a look at the changelog on the web site.
And, it's still free.

Memcached - Pros and Cons

We have a website at swalif.com which is like a news website based on forums. We are currently using a mysql database and things are getting slow. We decided to go with the Sphinx Search Server to speedup things and its been going quiet well.
Recently we heard of something called 'memcached' and just going through it we think we should look into it before moving to a search server completely.
My question is what are the pros and cons of using 'memcached' as it is a fairly new topic to us.
Thanking you
I just got my site set up with memcached a couple months back and it's amazing. The pros are rather obvious. It can be used to cache information that is, perhaps difficult to gather. The best example is an expensive mysql query. Check your slow query log, that would be a good starting point for things to parts to target. I had this one main page that took 2.5 seconds to echo from the server (horrible, I know). I had thought about changing the way it was written and it would have been very complicated. I put in memcached on the "difficult" parts of that page and now it's down to 0.001 seconds to parse. It's just amazing.
There is one main con that I've run into. If you update your content, you have to delete all associated keys related to that new content so that your front end will refetch the data and cache the new data. If not, you get stale content. I have tens of thousands of entries in my memcached and it's difficult to delete all the appropriate ones. If you don't, you'll get old content. One solution is to just set your key expiration duration to something short (24 hours). If you do that, you know that your site will reflect the newest content, at worst, 24 hours after a change. So if you can live with that, this problem is rather moot.
Bottom line, it's one of the best tools I've ever seen. It took me less than a day to install it on the lions share of my rather big site and the impact was tremendous.

How To Bid A Development Project?

I have landed a side project where a company wants me to develop a database / smart client to track participants in their various programs. This app will be written in C# and MS SQL Server.
I was wondering if there are any tips on how to actually bid out a price for the job?
Should I charge a flat rate (if so how do you charge it?)
Should I charge by the hour (if so what is a going rate?)
Should I enter into some sort of contract?
Any comments or tips would be very helpful, as I am completely new to doing "side gigs" outside of my normal programming job.
Thanks in advance
Yes you should enter into a contract, you need to spell out the terms and conditions of the work the expected deliverables and payment. You will also want to indicate who owns the source code.
I prefer Time & Material contracts, that is they pay an hourly rate. This allows them to change the scope without having to renegotiate the terms. If you go with a fixed bid project then as the users starts to learn what they want and change the specification, which they will, you will have to make a choice. Either you do it for free or you negotiate a scope change.
Your goal is to get the gig, and once you have it, make enough money for it to be worth your while, right? With that in mind, you can do flat rate if the client demands it, but otherwise try and get it hourly, because there will always be snags, and the client will always throw changes at you from the first day to the last minute that will suck down your time if you let it. Either way, get a contract that specifies what you are going to deliver and how to handle change requests.
I did a succession of fixed price contracts for a client once, and it worked great. Then they said they were having a little problem getting a signature on this contract from head-office, but if I were to just do the work they'd make sure I got paid for the work eventually. So I spent two months working on it, only to be told that they had been turned down by head office and so I wasn't going to get paid. I'm 90% sure they'd made a copy of my work before I could delete it from their servers, but nothing I could prove in court. So I'll never work without a signed contract again. If they don't sign a contract on day one, get the hell out of there.
If you're a beginner I'd advise against a flat rate ... unless you are prepared to shoulder the risk of more work than is paid for. It is inherently hard to estimate the effort a project takes.
The rate you can take depends on your market and how you value your time. It might be interesting accepting a low rate gig to get started in a certain market when you have free times at your hand or if you're just interested at the subject.
Well there are a few things you need to worry about.
Contract, yes, this is 100% needed, otherwise you might not get paid. The details of the contract are what might by challenging, especially about how to charge, which is what you're asking.
If you charge an hourly rate, you have to worry about being fair when you charge, and I'm sure the client will worry about this. If you're on the clock, it's not fair to check your email, YouTube, or even Stack Overflow (gasp!). Then there is also the question about whether you should charge if you need to learn some new skill. For example, if you have to learn library A, is this charged to the client or should it be done on your own time?
With a flat rate, you have to worry about keeping yourself productive so that you don't end up with a lower hourly rate. On the other hand, if the job turns out to be easy, you can finish quickly, and end up with a good hourly rate. This probably would be a lot more fair to both parties since no one would be monitoring you so that you're not goofing off and you wouldn't be doing something unethical if you decided to surf the internet while you're working.
If this is a side project and not a long-term job, I'd highly recommend a flat rate. Make sure you estimate it properly though. Take a guess of how many hours you think it will take you, add 20%, and then multiply this by some reasonable hourly rate. The other party will most likely be much more open to a flat rate since then it will be like they are paying for a finished product, rather than a developer.
Good luck!
Bidding is a tight rope walking game. Neither too low nor too much. The contract or the hourly rate always drives bidders mad. Be just in your bidding price and do not undercut too much else you might end up working for nothing. Also bid in such sites that hold the project price in escrow once the winning bidder is chosen. One good resource can be found at :- http://www.freelancing-on-net.com/writing_a_successful.php#
Even if you are bidding hourly, customers always want at least an estimate. Don't forget to account for all the activities that you don't think of when you're thinking of creating software.
Specifically, think of project management, meeting and call times with the client, end user meetings, source code management, testing, and bug fixing. In short, everything that you do for this client that prevents you from making money with another client needs to be billed to this client. You can account for that with the number of hours bid or with the hourly rate (usually a combination of the two).
I used to hear, "Prepare your best estimate. Then double it." Then I heard, "Prepare your best estimate, then times it by Pi." Now I hear, "Prepare your best estimate, then times it by Pi, then double it." :)
Unfortunately, the only way you'll get good at accurately bidding projects is to bid some, complete the project, and see where you were over or under.
You're always motivated to bid low to ensure that you get the project. But if you lose money doing a project for half your cost, getting the project might not have been a good thing.