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.
I created a simple python flask application with 256MB to play around with.
They state that they give up to 2GB free of ram... so I was way below it
After 30 min I see that I'm billed $0.02..
I tried to post it in their "stackoverflow" variant but I got 500 error :).. so my last resort is to ask here, maybe someone can clarify.
The fear will be to put an app there, forget about it, then at the end of the month you wake up with a $999 bill.
I don't really understand your concern, but I'm still going to try to help.
If you are afraid that you will be charged, this is not going to happen while you have the 30-days trial account. You will only have to pay if you decide to keep the account after the 30-days are over.
If you are afraid that you are being over-charged, you can always keep track of what you spent through the "View Full Usage Details", where there are all the pricing details (per region, per app, etc). You can also predict how much an app will cost beforehand using the calculator on the platform (https://new-console.au-syd.bluemix.net/?direct=classic/#/pricing/cloudOEPaneId=pricing&paneId=pricingSheet)
Lastly, if you are afraid that you will spend more than you want, there is a spending notification policy (which applies only to paid accounts, of course). I believe there is also an option to stop applications if they exceed a limit, but personally I haven't used these feature yet.
I hope this helps :)
I have an app I'm developing against Facebook that timed out a few hours ago during my first production use. Of course I tried to get it do too much and the http call timed out. So, I rewrote what I was doing to use threaded connections, which sped up the interaction significantly! However, I was so engrossed in getting my interaction to speed up (it equated to about 25-50 calls, not exactly sure, I was expecting 25 but some of my results show it was 50 times), I didn't even stop to think about how fast I was hitting facebook.
So, I started getting the "Uncaught OAuthException: It looks like you were misusing this feature by going too fast. You窶况e been blocked from using it." which is what I now get even if I try to run my program with only 1 hit. I've added a sleep into my system to limit the hits at 1/second, but I'm concerned that my app (that was not making public posts so no one could have been bothered by them) is now forever banned from facebook, as it says I'm banned from the feature with a reference to learn about blocks in the Help Center; except I can't find any reference in the Help Center to my specific situation.
Does anyone know how long my app is out of commission?
And what are the specific (reference please, because I've search the hell out of fb and can't find one) limits regarding speed at which you can access facebook?
It depends on what has blocked you. In this case it was a spam bot that stopped me from posting comments into a group. Apparently there is a non-specific number of times you can post comments in a group in a short amount of time. The amount varies, but hovers around 150ish give or take 50 (at the time of my tests).
The ban appeared to be consistently set to about 19 hours at that time (May 2014). I've confirmed by continued testing in test groups and subsequent bans. However, Facebook developers are unable to give a solid set of numbers as they say it's controlled by a spam algorithm which changes based on server usage. So, 150 comments within about 3 minutes = ban for about 19 hours.
I just finished my first iPhone app. It's a little game and I want to launch it for 99 cents.
So my concerns is, how long usually does an app stay on the new released list. ALso, is there any launching tips on timing etc?
Thank you
These days apps stay on the new app list for hours rather than days. It used to be that updates gave you better visibility but but my last update caused barely a blip in sales so I don't think it is true anymore. This will probably depend on the categories you are in though.
The goldrush is sadly over. It used to be that merely being in the app store generated hundreds or thousands of sales. That is definitely not true any more. Now you need either luck or marketing.
Things you can do:
Provide review copies to as many
sites as you can find. Most will
have limited visibility but if you
can get onto a bigger site you may
get some sales out of it.
Provide a free limited version.
Build a mailing list on your website
Pimp it everywhere. In your sig, on your website
Start writing the second game
ASAP - why wait, right? In reality, your true launch date is going to be determined by Apple anyways depending on how long it takes them to review and approve your app.
One tip I've heard is to update reasonably often.
When you update, your app may reappear on some of the category lists as being recently added/updated. This can give you some extra visibility which might just be what gets you ahead.
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.