Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Crowdsourced Dev QA

Options
  • 08-08-2016 10:42pm
    #1
    Registered Users Posts: 2,234 ✭✭✭


    Hi Folks,

    I'm in the process of writing an SDK and would like a bunch of devs to consume it to test it out and provide feedback / bugs.

    I believe there are sites like this available for general testing of apps/web sites but is there something where developers actually write code to use your SDK/APIs etc?

    Cheers


Comments

  • Registered Users Posts: 4,468 ✭✭✭CruelCoin


    techguy wrote: »
    Hi Folks,

    I'm in the process of writing an SDK and would like a bunch of devs to consume it to test it out and provide feedback / bugs.

    I believe there are sites like this available for general testing of apps/web sites but is there something where developers actually write code to use your SDK/APIs etc?

    Cheers

    Put it up on github or other repositories, make it publicly available and then pimp it on forums.


  • Registered Users Posts: 768 ✭✭✭14ned


    techguy wrote: »
    Hi Folks,

    I'm in the process of writing an SDK and would like a bunch of devs to consume it to test it out and provide feedback / bugs.

    I believe there are sites like this available for general testing of apps/web sites but is there something where developers actually write code to use your SDK/APIs etc?

    Cheers

    Programming language and what the SDK is for would be handy.

    One of the things the Boost C++ Libraries requires of new library submissions is that a design rationale document comprehensively surveys all existing alternatives, and provides a series of rationales why the alternatives aren't good enough. 95% of new libraries fail on that requirement alone.

    Niall


  • Registered Users Posts: 2,234 ✭✭✭techguy


    CruelCoin wrote: »
    techguy wrote: »
    Hi Folks,

    I'm in the process of writing an SDK and would like a bunch of devs to consume it to test it out and provide feedback / bugs.

    I believe there are sites like this available for general testing of apps/web sites but is there something where developers actually write code to use your SDK/APIs etc?

    Cheers

    Put it up on github or other repositories, make it publicly available and then pimp it on forums.

    That's a really good idea.. And it's also fairly obvious and I didn't think of that, so many thanks :)
    14ned wrote: »
    techguy wrote: »
    Hi Folks,

    I'm in the process of writing an SDK and would like a bunch of devs to consume it to test it out and provide feedback / bugs.

    I believe there are sites like this available for general testing of apps/web sites but is there something where developers actually write code to use your SDK/APIs etc?

    Cheers

    Programming language and what the SDK is for would be handy.

    One of the things the Boost C++ Libraries requires of new library submissions is that a design rationale document comprehensively surveys all existing alternatives, and provides a series of rationales why the alternatives aren't good enough. 95% of new libraries fail on that requirement alone.

    Niall

    Ok, well the SDK core is written in Go and there are a few wrappers (currently .NET, Java, C#.NET) that call into this core via RPC calls (Thrift).

    The SDK is for payments in the Internet of Things. I don't believe there are any other SDKs that offer similar functionality.


  • Registered Users Posts: 2,234 ✭✭✭techguy


    I reckon I may end up putting the kit on Github and generating interest, feedback etc.

    I will also hire people on programming market sites to give feedback. In theory the hiring of people is a good idea but I am doubtful that it will result in any valuable feedback.


  • Registered Users Posts: 2,022 ✭✭✭Colonel Panic


    Are you using Thrift RPC for interop between other languages and Go, or will clients written in these languages talk to a server written in Go?


  • Advertisement
  • Registered Users Posts: 2,234 ✭✭✭techguy


    Are you using Thrift RPC for interop between other languages and Go, or will clients written in these languages talk to a server written in Go?
    Using Thrift RPC to interop between other languages and Go. What do you think?


  • Registered Users Posts: 768 ✭✭✭14ned


    techguy wrote: »
    I reckon I may end up putting the kit on Github and generating interest, feedback etc.

    I will also hire people on programming market sites to give feedback. In theory the hiring of people is a good idea but I am doubtful that it will result in any valuable feedback.

    High quality feedback is worth a LOT of money. Ideally the feedback you'd want would be from experienced Go programmers, because if say I looked at your library I could only comment from an algorithmic and design point of view. I could say nothing about whether your code was secure, stable, well tested, well written or anything along those lines.

    Still, do post a link here if you do decide to put it up onto github. I'd be curious to poke through it even though I fear the emergence of IoT.

    Niall


  • Registered Users Posts: 2,022 ✭✭✭Colonel Panic


    techguy wrote: »
    Using Thrift RPC to interop between other languages and Go. What do you think?

    It's an interesting approach! It would certainly cut down on the amount of boilerplate you'd need to write.

    What transport do you use?


  • Registered Users Posts: 2,234 ✭✭✭techguy


    14ned wrote: »
    techguy wrote: »
    I reckon I may end up putting the kit on Github and generating interest, feedback etc.

    I will also hire people on programming market sites to give feedback. In theory the hiring of people is a good idea but I am doubtful that it will result in any valuable feedback.

    High quality feedback is worth a LOT of money. Ideally the feedback you'd want would be from experienced Go programmers, because if say I looked at your library I could only comment from an algorithmic and design point of view. I could say nothing about whether your code was secure, stable, well tested, well written or anything along those lines.

    Still, do post a link here if you do decide to put it up onto github. I'd be curious to poke through it even though I fear the emergence of IoT.

    Niall

    Yes, I agree, but that said, the best feedback is not always paid for. We've finally made a release to < https://github.com/WPTechInnovation/worldpay-within-sdk/ > All feedback welcome.
    techguy wrote: »
    Using Thrift RPC to interop between other languages and Go. What do you think?

    It's an interesting approach! It would certainly cut down on the amount of boilerplate you'd need to write.

    What transport do you use?

    Yes, it turns out the wrappers are really lightweight. All we need is an interface to abstract the Thrift layer and adapters to convert the Thrift types. The tricky piece is actually launching the Go RPC agent binary and shutting it down in a clean manner as well as runtime errors into the wrapper application.


  • Registered Users Posts: 768 ✭✭✭14ned


    techguy wrote: »
    Yes, I agree, but that said, the best feedback is not always paid for. We've finally made a release to < https://github.com/WPTechInnovation/worldpay-within-sdk/ > All feedback welcome.

    As I mentioned, I can't comment usefully on it technically. It looks okay to me at least. But I would make the following observations:

    1. Open source needs to not look like a dump of some internal project nowadays for anyone to use it, and getting status badges onto your github Readme.md for per-commit CI testing via Travis, Appveyor and CircleCI is wise. Extra bonus points for per-commit test coverage calculation via coveralls.io.

    2. Increasingly you ought to have those CIs package up a binary distro if all tests pass and push to the common binary repos. For C++ libraries, that would be launchpad for Ubuntu, Nuget for MSVC, for python it's pypi.org. I assume there is something similar for IoT devices.

    3. My single biggest worry flicking through your docs was "how much RAM is this thing going to consume?" given my likely very RAM limited IoT device which has no swap file. A graph showing RAM consumption to load over time is the gold standard here.

    4. Perhaps I'm a bit old fashioned, but I wouldn't be touching Java nor NodeJS for an IoT application. Too hefty. I'd be looking for some C language bindings preferably as SWIG wrappers, those can be bound into almost any language or runtime under the sun.

    Anyway I may have totally missed the scope of your library, I was just trying to imagine if I were writing an IoT app and needed to talk to payment systems, so it's about what would be my priorities and what would worry me when evaluating whether to use some open source solution versus rolling my own using curl.

    Niall


  • Advertisement
  • Registered Users Posts: 2,234 ✭✭✭techguy


    Hi Niall,

    Many thanks for the valuable feedback and apologies for the delay responding. We value your feedback a lot and I would like to respond to each item.

    Many thanks,
    Conor
    Open source needs to not look like a dump of some internal project nowadays for anyone to use it, and getting status badges onto your github Readme.md for per-commit CI testing via Travis, Appveyor and CircleCI is wise. Extra bonus points for per-commit test coverage calculation via coveralls.io.

    I agree, but unfortunately we just don't have the bandwidth to do this thing right now. I understand that the bar is quite high in the OSS community these days. If we get traction this will get done.
    Increasingly you ought to have those CIs package up a binary distro if all tests pass and push to the common binary repos. For C++ libraries, that would be launchpad for Ubuntu, Nuget for MSVC, for python it's pypi.org. I assume there is something similar for IoT devices.

    Yes, I agree and have distribution to the various repos on the back log.
    My single biggest worry flicking through your docs was "how much RAM is this thing going to consume?" given my likely very RAM limited IoT device which has no swap file. A graph showing RAM consumption to load over time is the gold standard here.

    That's a reasonable concern I guess but the primary goal of this SDK is to enable developers to integrate via social events such as Hackathons etc. You could say that it is in an incubation, alpha phase where full "productization" has not yet occurred. Your kind of feedback is exactly what we are looking for to help shape any product that may come from this.
    Perhaps I'm a bit old fashioned, but I wouldn't be touching Java nor NodeJS for an IoT application. Too hefty. I'd be looking for some C language bindings preferably as SWIG wrappers, those can be bound into almost any language or runtime under the sun.

    Firstly, I don't think Node.JS and Java are too hefty, not all IoT devices are tiny, sparsely resourced machines and on the flip side, your credit/debit card is most likely running a flavour of Java. For this version our Thrift RPC implementation has worked well but could potentially pivot during product develop if needed for device support. Actually, considering the core component is written in Go which can compile to a Shared Object it should not be a huge task to create SWIG wrappers. ref: SWIG & Go Do you accept the challenge? :)
    Anyway I may have totally missed the scope of your library, I was just trying to imagine if I were writing an IoT app and needed to talk to payment systems, so it's about what would be my priorities and what would worry me when evaluating whether to use some open source solution versus rolling my own using curl.

    No, I don't think you have missed anything really. Our vision for this device is not so much about talking directly to a payment system but also allowing devices to communicate directly to each other and programmatically discover services and the transfer (and payment) of value.

    Again, thank's again for your input.


Advertisement