Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I am interested about playing with algorithmic trading strategies. Does anyone know if there exists simulator or benchmark data I could possibly play with offline (without actually making any investments)?
This question is pretty broad; as it is, there is no mention of which instruments you're interested in. For instance:
Stocks
Bonds
Commodities
Forex
Derivatives (like Futures or Options)
For the moment, I will assume you're interested in stocks... if so, take a look at Ninja Trader, which offers these features for free. You can get free end-of-day stock data from Yahoo Finance, which is sufficient for longer-term trading timelines; keep in mind that the shorter the trading cycle, the more stringent your data resolution needs to be.
If you are willing to put several thousand into a trading account, any number of brokers will be happy to send you live market intra-day market feeds; but you don't need money in an account for paper trading (at least with my broker). I think the broker that is most flexible for programmers is Interactive Brokers. You can get sub-second data from them via an API, just understand they won't give you Tick-level granularity; they summarize their feeds, the specific details vary so it's better just to talk to them if you have tight granularity requirements. As for off-line simulation, you can do that with Ninja Trader, Interactive Brokers, and many other online brokers (see What online brokers offer APIs?).
BONUS MATERIAL
Since you're offering +200, I will share a bit more that you might be able to use... Keep it or toss in the trash for whatever value it brings.
Trading Timeframe
As a general rule, the shorter the timeframe, the more difficult the trades, and the harder it is to consistently make money. If you're unsure where to start with timelines, look at trading cycles of days or weeks at a time; then if you see too many opportunities passing you by, refine your system to a smaller timeline. The other thing to consider is how often you want to touch this code and tweak algorithms. The general rule is, as the trading cycles get shorter, you do more calibration and maintenance on your algorithms. It is not that unusual to find an algorithmic trader who wrote a good Swing-Trading platform that has worked as-is for the last decade. On the other hand, Day Trading Algorithms tend to require more care and feeding based on changes in market conditions.
Trading Style
Closely related to timelines are your trading tactics. Are you:
Trend-Following
Swing-Trading
Day Trading
Scalping
Sub-pennying
Using Statistical Arbitrage
Playing Options
Trade Management / Mindset
Trade management is a rather big topic, and one you'll find addressed in-depth if you lurk around trader boards like Elite Trader. While it may sound out of place to discuss some of this in the same thread about automated trading platforms, I'm sure you'd agree that your assumptions and attitude have insidious ways of leeching into your code. I will share a few things off the top of my head:
Success is primarily about preventing losing trades. Good trades take care of themselves.
Always trade with a stop-loss. Conventional wisdom is, "Your first loss is your smallest loss". If things start going south, figure out a way to consistently get out while keeping most of your previous profits; holding losers is the fast path to becoming a boiled frog.
There is no such thing as "Too High" or "Too low". The market moves in herd-mentality and doesn't care what you think it should be doing.
Closely related to point "3": Trade with the long-term trend. Fighting the trend (affectionately known as "counter-trending") may sound attractive to natural contrarians, but you need to be very good to do it well. Trading is enough work without trying to counter-trend.
Trading within the hour after a Federal Reserve market announcement is very difficult; I think it's just better to be out of the market. The quick profits can look seductive, but this is where the pros love to eat the amateur traders; brutal reversals can develop within a couple of minutes.
Avoid trading on margin unless you have a proven technique that you have backtested with at least a couple years of data.
The first thrity-minutes and last hour of regular trading can see rapid changes in volatility.
Regarding profit taking, "Bulls get fed, hogs get slaughtered"
If you find that you are not making profits, consider evaluating your trading frequency; reducing your trades to a minimum is key to success, otherwise, slippage, commissions and fees on junk trades will eat your profits.
Due to computational delays / processing time and partial order fills, limit orders are rather challenging to manage and pretty close to minutia; algorithmic traders have much bigger fish to fry.
Coding
Log every data point and decision you make in your code; three logging levels works for me. Trading is an inexact task, and tiny changes can blow up your previously-profitable algorithm. If something blows up, you need a way to compare against what was working.
Prototype in a scripting language; if something is slow, you can always offload to a compiler later. I think python is a fantastic for quantitative finance... mature unit-testing, C / C++ integration, numpy, pyplot and pandas are winners for me.
More pandas plugs... (pandas video), also see: Compute a compounded return series in Python
I started off with plain-ole csv, but I'm in process of migrating to HDF5 for tick data archives
Trade-simulation is deceptive: Simulated trades don't have problems filling due to low-liquidity or high-demand for the instrument; depending on market conditions, my real trades can see two or three seconds delay from the time I send the order to the time I get a fill. Simulated trades also don't get data blackouts; be sure to include sudden data loss (and how to recover) in your plans. Lower-cost brokers tend to suffer more blips and blackouts, but if your timeframe is longer, it may be something you can ignore.
Legal
The information set forth herein has been obtained or derived from sources believed by author to be reliable. However, the author does not make any representation or warranty, express or implied, as to the information’s accuracy or completeness, nor does the author recommend that the attached information serve as the basis of any investment decision. This data has been provided to you solely for information purposes and does not constitute an offer or solicitation of an offer, or any advice or recommendation, to purchase any securities or other financial instruments, and may not be construed as such. By using any of this information, you expressly agree that all risks associated with the performance and quality of the information is assumed solely by you. The author shall not be liable for any direct, indirect, incidental, special or consequential damages arising out of the use of or inability to use the information, even if the author has been advised of the possibility of such damages. The information is made available by the author "as is" and "with all faults".
Is this the kind of data you're looking for?
Ohio Department of Finance, Financial Data Finder
This page might also be of help:
Yahoo Finance Download, HTTP Interface parameters
And this one:
mathfinance.cn: Free financial resources
Not offline, but still a good link to give to other readers:
Google Finance API
I hope I understood the question correctly.
I use AMIBroker.
Its primarily used for backtesting algorithmic trading strategies. It is very fast and can download and get data from a variety of free sources.
Try with Cloud based backtesting Engines like Quantconnect and Quantopian
Quantopian is a python based IDE where you can write strategies and backtest online. You can do simulation trades as well as real trades with Interactive Broker.
Quanconnect is similar to Quantopian and they used .Net Based IDE and you can run simulation trades and live trader with the discount broker tradier.
QuantGo lets you rent high frequency data sets rather than buying them. I really like it because it's only a couple hundred per month instead of thousands.
Quandl has some good free data sets if you are only interested in trading at longer time intervals. Their stock data API is pretty slick (link).
One alternative would be PyAlgoTrade (http://gbeced.github.io/pyalgotrade/). Its an open source Python library to backtest trading strategies.
I'm part of a software development company where we do custom developed applications for our clients.
Our software uses MS SQL Server and we have encountered some customers which do not have a DBA on staff to manage the databases or if they do, they lack the necessary knowledge to perform their job adequately.
We are in the process of drafting a contract with one of those customers to provide development services for new functionality on our software during the next year, where they have an amount of hours available for customization of our software.
Now they want us to include also a quote for database administration services and the problem is that they are including a clause that says that those services will be provided only when they request it.
My first reaction is that db administration is an ongoing process and not something that they can call us once a month to come for a day or two. I'm talking about a central 1TB+ MSSql Cluster and 100 branch offices with MSSql Workgroup edition.
My question is for any suggestions on how I could argue that there must be a fixed amount of hours every month for dba work and not only when their management thinks they need it (which I’m guessing would only be when they have a problem).
PS: Maybe this will be closed as not programming related. But I'm a programmer and I have this problem. My work is software development but i don't want to lose this client and the only solution I can think of is to find a way for the client to understand the scope so we can hire a qualified DBA to provide them with the service they require.
Edit: We are in a Latin American country with clients in the Spanish speaking region. My guess is that in more developed countries there is a culture that knows how delicate the situation is.
This is definitely one of those 'you can lead a horse to water, but you can't make them drink' situations.
My recommendation here would be to quote the DBA services as hourly, and make the rate high enough that you can outsource the work if you decide you want to. When (not if) the SQL servers start to have problems, the firm is on the hook.
I would also recommend that you include in your quote a non-optional 2 hour database technology review once per year. This is your opportunity to say 'You spent XXX on database maintenance this year, most of which was spent fighting fires that could have been easily avoided if you had just spent XXXX/4 and hired a DBA. We care about you as a customer, and we want you to save money, so we really recommend that you commit to using a DBA to perform periodic preventative maintenance'.
I would also recommend that you categorize any support requests as having root cause b/c of database maintenance vs other causes. This will let you put a nice pie chart in front of the customer during their annual review (which they are going to pay you to perform). It is critical to manage the perception so they don't think your code is causing the problems. You might even go so far as to share these metrics (db related issue vs non-db related issue) with them on a quarterly basis.
Sometimes people need to experience pain before they change. The key is to not be in between the hammer and their thumb as they learn the lesson, and hourly quoted work is one way of doing this.
As a side note, this sort of question is of great interest to a large number of developers. I'd say that this sort of thing could impact a programmer's quality of life more than any algorithm or library question ever could. Thanks for asking it!
No DBA on a system that size is a disaster waiting to happen. If they don't understand that, they are not qualified to run a database that size. I'd recommend that they talk to other companies with similar sized databases and have them ask them about their DBAs and what they do for them, and if they think they could survive without them.
Perhaps the link below from MS SQL Tips could give you some good talking points. But people who aren't technical wont respond to a technical explanation of the necessity of good DBA you are likley going to have to work toward proving the cost of bad DBA. Work out the worst case scenarios and see how they feel about them. If you can make it seem like a good financial move (and I think we all know it is) it will be an easy sell.
http://www.mssqltips.com/tip.asp?tip=1278
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
In my company we often value the software to be almost the same as concurrent software on the market. While this is one way I'm interested of other (maybe more academic) ways of value and put a price on software.
Any ideas or methods that have been succesful for you?
While I'm not always a fan of Joel, this crusty old article from 2004 answers your question very well. You charge based on how many units you think you will sell at that price, with the goal of maximizing profit.
I've done some contract work in the past, and I based my estimate on:
The cost of the man hours to produce the software, from start to finish
Potential money the client saves by using the software
Cost of any planned support for the software
Any other related costs such as installation fees, documentation, training, etc.
Then I compared that to the industry standard. In my case it was usually cheaper, and I still made money. Thus both the client and myself were happy.
Edit:
Mind you the above method is for a single client, with a custom software solution, and a simple unlimited-use license.
If you want to know academic methods for pricing a product, I have an MBA I would like to sell you.
Seriously, it depends on a lot of things. Are you selling a service, subscription, or a "box"? Where is your desired position in the market? What do your customers have to spend?
Listen to your customers and be prepared to change your pricing strategy. If you ever hear a customer say, "Wow, I was expecting to pay more!", it may be time to raise your prices significantly.
Magsto, my bet is that this question will be closed pretty quickly as being "not programming related."
However, I will tell you that your question is quite a bit more complex than can be answered here. There are lots of factors including time in market, market size, ROI you can offer, competitive advantages or disadvantages, the structure of payments (credit card, purchase order, cash), and even time of year. I only have experience here because I run my own company.
Do you really want to ask programmers this question? I think not...
I value my product as a fraction of it's value for the client. My venture sells web apps so it's slightly different, but if a web app would streamline 75K worth of overhead out of an office's budget, I charge 25K for it.
If it's a one time sale you have the option to examine the client and what value it will deliver to them. If it's a publicly sold product, the options are very different.
The basic formula is to sell it for around 30% of what it's worth to clients/end users. If you can deliver better quality than the next company, pricing in step with them is a big mistake because you can make more and take a better market share by promoting the features that justify the cost.
Customers often perceive cost as equal to quality. If you want to position your product as the highest quality option, you might consider pricing at 20% more than other competitors.
The price of a product is just as much about market strategy as maximizing profit.
You might want to read this:
Securing a .NET Application
It's a bit long, but I do get into some pricing at the end.
I am a IT enterprenuer and I my venture is into web and application development domain. When we deliver any product to our clients we ask them that
-how much time they are able to save with our application in place.
-Then we ask them to value their own time. Ex how much do they make in an Hour
-Then we do
time saved * value of time (as per the client)
these is the value that turns out for one day. We do the similar computations and demonstrate them how much they save in month and in a year
Thereafter depending on the client and the result for monthly and annual saving we give them the final price quote.
We think that these is the best way to give a software pricing as in these process we are pricing the software as per the money that software is helping our client to save
I have looked around on net and these book was suggested on almost all the forums though I have not personally been through these book but here is the download link
Dont just roll the dice
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
A while back I worked with a software company that sold a specialized software product. Ever so often they would release a patch for free and a new version that would require an upgrade fee. This is typically how the software industry works.
After some time the company decided on a new strategy, Subscription based software. This turns out to be a way for the software company to charge a small, incremental fee for each "transaction" that is performed on their software. Under this model the patches and upgrades were included in the per/transaction fee and there was a 'true up' in the number of transactions every so often in order to collect their fees.
To me this seems like a better way to develop and sell software. The software company gets continual income stream, the customer doesn't have to worry about upgrade costs and such, and if the customer gets really big then your income stream grows with their growth.
The problem (and reason for this question) is that I don't see anyone doing that anymore. Is it because this model doesn't work? Have I taken an overly simplistic view of developing and selling software without seeing some of the negative sides of this model?
[EDIT] I am interested in the developers opinion on whether writing Subscription based software is a good way to develop software.
So this question is directed towards the professional developers who have worked on commercial applications: Can anyone speak with experience on this model and why it does/doesn't work?
I used to work for a company which moved from product license to subscription based model. Here are some observations about that:
Offer both product license and subscription models
In product license: user buys 'n' number of seats for their use.
In subscription models, customer buys your software for 'x' months time and 'y' people.
It will help you a lot if your company also develops 'consultants' who will work with your customers to get the software implementation etc at client site (any required installation, training etc)
In fact if you see services like GMail enterprise, Fogbuz etc they give different pricing options:
where you want the app hosted: your servers or their servers
you will be charged $x per number of people using the software
I think a subscription model (time based) will definitely work in the current times and in fact the cloud model helps towards such freedom in revenue models: for example, you can choose to 'subscribe' to a cloud database rather than purchasing a database server.
Yes it does. See salesforce.com for an example.
Red Hat seems to think it works. Buy a year of support get all the upgrades/etc/etc. Except they let you keep the product when the year is up (so.. I guess customers like that too =).
It's not exactly the same but basecamp from 37Signals is very succesful with a monthly fee basis, and FogBugz also uses the same model. The approach you're talking about here seems similar to the MircoPayment idea that was seen as a revenue earner in the early days on the web. I'm not sure if anyone succesfully made money from that model, I'm sure a lot of VC was spent trying.
[Edit] I think this an exellent way for small ISVs to run their businesses. The combination of SAAS and subscription is a great way of getting revenue quickly. There are a number of advantages
1) Continuous revenue
2) Small or zero initial payment, brings customers in, beats that credit card price point issue (it's easier to charge $10/month than $100 one off)
3) Builds a solid relationship between ISV and vendor
4) Chance to upsell, assuming the offering is good
And the only way you're going to be a big software vendor is by being a small one first.
Due to the nature of software development a subscription based model is really the way to go, but how do make sure that you have continues updates that actually make software worth subscription fees.
If you're providing a service it's a lot easier to motivate subscription frees but if you're planning on having people pay monthly for monthly releases, well than that's a thin line between success and utter failure. I don't see how this would work with most software.
Update: #Dscoduc
I would call that a service then. Make a clear distinction between software release schedule and support. If you want to charge for a premium support deal well that service gonna have to be pristine. But I do see how it could work. People might end up buying subscription based software on the premises that they will be able to tailor it to fit their needs without programming experience and at a low cost.
Your challenge lies in being able to listen to your customers and really find a way of taking their feedback and making that the foundation for your software life-cycle and that's not going to be an easy thing to do.
Maybe we should petition stackoverflow for a way of marking content not related to programming but interesting to programmers.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I wrote a utility for photographers that I plan to sell online pretty cheap ($10). I'd like to allow the user to try the software out for a week or so before asking for a license. Since this is a personal project and the software is not very expensive, I don't think that purchasing the services of professional licensing providers would be worth it and I'm rolling my own.
Currently, the application checks for a registry key that contains an encrypted string that either specifies when the trial expires or that they have a valid license. If the key is not present, a trial period key is created.
So all you would need to do to get another week for free is delete the registry key. I don't think many users would do that, especially when the app is only $10, but I'm curious if there's a better way to do this that is not onerous to the legitimate user. I write web apps normally and haven't dealt with this stuff before.
The app is in .NET 2.0, if that matters.
EDIT: You can make your current licensing scheme considerable more difficult to crack by storing the registry information in the Local Security Authority (LSA). Most users will not be able to remove your key information from there. A search for LSA on MSDN should give you the information you need.
Opinions on licensing schemes vary with each individual, more among developers than specific user groups (such as photographers). You should take a deep breath and try to see what your target user would accept, given the business need your application will solve.
This is my personal opinion on the subject. There will be vocal individuals that disagree.
The answer to this depends greatly on how you expect your application to be used. If you expect the application to be used several times every day, you will benefit the most from a very long trial period (several month), to create a lock-in situation. For this to work you will have to have a grace period where the software alerts the user that payment will be needed soon. Before the grace period you will have greater success if the software is silent about the trial period.
Wether or not you choose to believe in this quite bold statement is of course entirely up to you. But if you do, you should realize that the less often your application will be used, the shorter the trial period should be. It is also very important that payment is very quick and easy for the user (as little data entry and as few clicks as possible).
If you are very uncertain about the usage of the application, you should choose a very short trial period. You will, in my experience, achieve better results if the application is silent about the fact that it is in trial period in this case.
Though effective for licensing purposes, "Call home" features is regarded as a privacy threat by many people. Personally I disagree with the notion that this is any way bad for a customer that is willing to pay for the software he/she is using. Therefore I suggest implementing a licensing scheme where the application checks the license status (trial, paid) on a regular basis, and helps the user pay for the software when it's time. This might be overkill for a small utility application, though.
For very small, or even simple, utility applications, I argue that upfront payment without trial period is the most effective.
Regarding the security of the solution, you have to make it proportional to the development effort. In my line of work, security is very critical because there are partners and dealers involved, and because the investment made in development is very high. For a small utility application, it makes more sense to price it right and rely on the honest users that will pay for the software that address their business needs.
There's not much point to doing complicated protection schemes. Basically one of two things will happen:
Your app is not popular enough, and nobody cracks it.
Your app becomes popular, someone cracks it and releases it, then anybody with zero knowledge can simply download that crack if they want to cheat you.
In the case of #1, it's not worth putting a lot of effort into the scheme, because you might make one or two extra people buy your app. In the case of #2, it's not worth putting a lot of effort because someone will crack it anyway, and the effort will be wasted.
Basically my suggestion is just do something simple, like you already are, and that's just as effective. People who don't want to cheat / steal from you will pay up, people who want to cheat you will do it regardless.
If you are hosting your homepage on a server that you control, you could have the downloadable trial-version of your software automatically compile to a new binary every night. This compile will replace a hardcoded datetime-value in your program for when the software expires. That way the only way to "cheat" is to change the date on your computer, and most people wont do that because of the problems that will create.
Try the Shareware Starter Kit. It was developed my Microsoft and may have some other features you want.
http://msdn.microsoft.com/en-us/vs2005/aa718342.aspx
If you are planning to continue developing your software, you might consider the ransom model:
http://en.wikipedia.org/wiki/Street_Performer_Protocol
Essentially, you develop improvements to the software, and then ask for a certain amount of donations before you release them (without any DRM).
One way to do it that's easy for the user but not for you is to hard-code the expiry date and make new versions of the installer every now and then... :)
If I were you though, I wouldn't make it any more advanced than what you're already doing. Like you say it's only $10, and if someone really wants to crack your system they will do it no matter how complicated you make it.
You could do a slightly more advanced version of your scheme by requiring a net connection and letting a server generate the trial key. If you do something along the lines of sign(hash(unique_computer_id+when_to_expire)) and let the app check with a public key that your server has signed the expiry date it should require a "real" hack to bypass.
This way you can store the unique id's serverside and refuse to generate a expiry date more than once or twice. Not sure what to use as the unique id, but there should be some way to get something useful from Windows.
I am facing the very same problem with an application I'm selling for a very low price as well.
Besides obfuscating the app, I came up with a system that uses two keys in the registry, one of which is used to determine that time of installation, the other one the actual license key. The keys are named obscurely and a missing key indicates tampering with the installation.
Of course deleting both keys and reinstalling the application will start the evaluation time again.
I figured it doesn't matter anyway, as someone who wants to crack the app will succeed in doing so, or find a crack by someone who succeeded in doing so.
So in the end I'm only achieving the goal of making it not TOO easy to crack the application, and this is what, I guess, will stop 80-90% of the customers from doing so. And afterall: as the application is sold for a very low price, there's no justification for me to invest any more time into this issue than I already have.
just be cool about the license. explain up front that this is your passion and a child of your labor. give people a chance to do the right thing. if someone wants to pirate it, it will happen eventually. i still remember my despair seeing my books on bittorrent, but its something you have to just deal with. Don't cave to casual piracy (what you're doing now sounds great) but don't cripple the thing beyond that.
I still believe that there are enough honest people out there to make a for-profit coding endeavor worth while.
Don't have the evaluation based on "days since install", instead do number of days used, or number of times run or something similar. People tend to download shareware, run it once or twice, and then forget it for a few weeks until they need it again. By then, the trial may have expired and so they've only had a few tries to get hooked on using your app, even though they've had it installed for a while. Number of activation/days instead lets them get into a habit of using your app for a task, and also makes a stronger sell (i.e. you've used this app 30 times...).
Even better, limiting the features works better than timing out. For example, perhaps your photography app could limit the user to 1 megapixel images, but let them use it for as long as they want.
Also, consider pricing your app at $20 (or $19.95). Unless there's already a micropayment setup in place (like iPhone store or XBoxLive or something) people tend to have an aversion to buying things online below a certain price point (which is around $20 depending on the type of app), and people assume subconciously if something is inexpensive, it must not be very good. You can actually raise your conversion rate with a higher price (up to a point of course).
In these sort of circumstances, I don't really think it matters what you do. If you have some kind of protection it will stop 90% of your users. The other 10% - if they don't want to pay for your software they'll pretty much find a way around protection no matter what you do.
If you want something a little less obvious you can put a file in System32 that sounds like a system file that the application checks the existence of on launch. That can be a little harder to track down.