A suitable language to build a bot for a complete beginner?

User avatar
Euler
Posts: 19981
Joined: Wed Nov 10, 2010 1:39 pm
Location: Bet Angel HQ
Contact:

Difficult to forgive him for the way he acted as an 'expert' and then got stuck into me to imply I'd never been profitable to any extent. I even contacted him from half way around the planet to invite him to a meeting, so he could see I was genuine. But he declined and was incredibly disrespectful and patronising. It was along the lines of 'I'm more intelligent than you and if I can't do it, then neither can you'. Intensely arrogant, but somewhat amusing that he was forced to admit that he was unprofitable.

I think it shows that there is an intelligence trap when trading. I'll always have a lot of respect for people that trade profitability, however they do it. But I've got none for people who pretend to trade or are dismissive of those that do. They are many ways to make this work and if you may it work, then you deserve some respect.
User avatar
Euler
Posts: 19981
Joined: Wed Nov 10, 2010 1:39 pm
Location: Bet Angel HQ
Contact:

I'd echo the comments about time taken to develop something. You seem to spend most of your time debugging and testing, it can take ages.

Very often it's not the things you know about that catch you out, it's the stuff that you didn't that has the biggest impact.
User avatar
ShaunWhite
Posts: 6188
Joined: Sat Sep 03, 2016 3:42 am

Euler wrote:
Sat Jun 15, 2019 2:43 pm
I'd echo the comments about time taken to develop something. You seem to spend most of your time debugging and testing, it can take ages.
:D So so true. The last 10% often takes 90% of the time.

This is why we always used to massively frontload all our development and spend as much as 40 or 50% of the budget on analysis, design, speccing etc etc.

The best advice I have is to write your unit and system test plans before even a line of code is written. Otherwise you just end up testing what you wrote, not a testing vs the original objective.
firlandsfarm
Posts: 1296
Joined: Sat May 03, 2014 8:20 am

ShaunWhite wrote:
Sat Jun 15, 2019 4:20 pm
The best advice I have is to write your unit and system test plans before even a line of code is written. Otherwise you just end up testing what you wrote, not a testing vs the original objective.
Great advice Shaun
User avatar
ShaunWhite
Posts: 6188
Joined: Sat Sep 03, 2016 3:42 am

firlandsfarm wrote:
Sat Jun 15, 2019 4:28 pm
ShaunWhite wrote:
Sat Jun 15, 2019 4:20 pm
The best advice I have is to write your unit and system test plans before even a line of code is written. Otherwise you just end up testing what you wrote, not a testing vs the original objective.
Great advice Shaun
Sounds a bit OTT but it's amazing what can slip through the net between speccing and delivery if you're not careful, especially when coding gets split between a dozen people who don't know the big picture. I started in dev when there weren't really any formal methodologies like there are today, I was writing my own rule book and things like that which are now common practice had to be learnt the hard way. :)
greenmark
Posts: 965
Joined: Mon Jan 29, 2018 2:15 pm

I think that applies with backbone systems. The Agile approach is more suited to rapidly creating a web-friendly front-end, and adapting it as time goes on.
ShaunWhite wrote:
Sat Jun 15, 2019 5:57 pm
firlandsfarm wrote:
Sat Jun 15, 2019 4:28 pm
ShaunWhite wrote:
Sat Jun 15, 2019 4:20 pm
The best advice I have is to write your unit and system test plans before even a line of code is written. Otherwise you just end up testing what you wrote, not a testing vs the original objective.
Great advice Shaun
Sounds a bit OTT but it's amazing what can slip through the net between speccing and delivery if you're not careful, especially when coding gets split between a dozen people who don't know the big picture. I started in dev when there weren't really any formal methodologies like there are today, I was writing my own rule book and things like that which are now common practice had to be learnt the hard way. :)
User avatar
ShaunWhite
Posts: 6188
Joined: Sat Sep 03, 2016 3:42 am

greenmark wrote:
Sat Jun 15, 2019 7:03 pm
I think that applies with backbone systems.
True, I'm taking about substantial systems, but I feel the principal still applies.

I'm not a fan of Agile and I think it's damaged the reputation of the industry tbh. It's legitimised dumping a v1.0 on people and 'adapting' it when enough people complain. or enough people buy it to consider it worth finishing. I'm much more of the school did things once and did them right, unfortunately that takes time and money people seem reluctant to spend these days. My view is probably just a symptom of the type of software I was involved in, whereby flaws of any kind were simply not an option and upgrades would be annual instead of weekly to minimise risk. If you're just knocking out an app or a website you can probably just about wing-it, and if you want to give that method a fancy name dreamt up in California to sell books and courses then so be it.

Sorry greenmark that's not a dig at your comment, it's just the miserable grumblings of a jaded Greybeard :roll: "Kids these days eh......"
User avatar
johnsheppard
Posts: 214
Joined: Mon Feb 04, 2019 6:00 am
Location: Cairns Australia

I would think for a single programmer operation writing bots somewhere in between waterfall and agile would be the way to do it...

My own personal experience has been that my goals have changed several times and that has been a result of applying prototyped code.
One might argue that was because when I started I didnt have a clue what I was doing (in terms of domain knowledge)...which a waterfall model might have fixed early...

On there other hand if you are really new at things.....you're gonna make errors, not sure if waterfalling things is going to help you save time...making the huge mess that comes from being noob is probably unavoidable....no point waterfalling errors...

e.g. you're building a house...never built one before....don't really know what the house has to do.....its hard to write a requirments specification... you're probably better off building a cubby house without plans first...

another e.g. you're building a house for clients. you've built houses before. You know the pitfalls...you know exactly what you're doing....writing requirements and adjusting requirements via consultation is quicker than building a cubby house to identify errors... i.e. if you know what you're doing the earliest and cheapest place in the process is to adjust via requirement specifications...
Xeres
Posts: 47
Joined: Mon Jun 03, 2019 2:56 pm

I purchased both books by James Butler and I found them to be quite useful, I followed all the code and built the app in VB and it was fairly simple, although the errors were an absolute pain. I didn't end up using it myself but it helped me to understand the API a bit more.

If your going to be developing other strategies then I would say you should use Python or R. I personally use R because I think it's easier to set up, has a nicer IDE and there is a lot more support for it. Python is more general purpose so it does depend on what you are doing.

The reason I say use Python/R is because building prototypes in say R for example is very easy and very fast. You can connect to the Betfair API and store data with just a few lines of code, you can be very lazy and not even bother creating tables and definitions in MySQL, R will create them all for you.

You can also use R in a production environment, I do this personally but also at work, it's not going to be as fast as C++ but you'll be amazed at how fast it can manipulate large volumes (100M+ rows) of data as long as you use the correct library.
User avatar
Euler
Posts: 19981
Joined: Wed Nov 10, 2010 1:39 pm
Location: Bet Angel HQ
Contact:

I've been interested in learning R purely for data analysis. Though never having even looked at it, I'm not sure what advantages it would offer. I only have a sketchy appreciation of why people use it for number crunching.
Post Reply

Return to “Betfair Exchange API”