Anyone taken a Spin in the Cloud?
Erlend
Posts: 612
I just wondered, have anyone here moved into the Cloud - instead of having the Spin files on a local harddrive. And how well would that work with Propellor Tool?
I am asking because at work I have just been introduced to how software development 'these days' are done in the Cloud - and it seems amazing to me.
Erlend
I am asking because at work I have just been introduced to how software development 'these days' are done in the Cloud - and it seems amazing to me.
Erlend
Comments
For some, like localroger above it's just a matter of having a share between local an remote machines. Crude but effective in some cases. Lacks version control, like git, which is a shame.
For my daily work the work flow is a) Pull code from it's source repository at github. b) Add or fix some feature, b) Push code back to github at some meaningful point. c) I or someone else pulls code from github to testing servers in the google cloud or AWS or wherever. d) Eventually code finds it's way to production servers.
Recently for fun I have been playing with the services of resin.io https://resin.io/. Using resin again I keep code in github, but pushing it to another repo maintained by resin causes it to be rebuilt on their servers and then deployed to one or more remote IoT targets. Currently they support Raspberry Pi, Beagle, Parallella, Edison boards with more coming. Resin.io is magic! See my remotely, resin deployed, raspberry pi camera test page here: http://bccbb0d6f38d1c3dec17eaeddc737106d477d88a61d67d23ac5acf2adb463c.resindevice.io/
Then of course there are things like complete web based IDEs. Like Cloud9 https://c9.io/ No need to ever install any dev tools on the local machine, all happens in the "cloud".
When it comes to the Propeller and Spin that can be done to. I created a proof of concept Spin IDE that edit's and compiles Spin projects from the remote web site all in the browser. http://the.linuxd.org/lab/spine.html Sadly development on that ceased due to lack of time but the demo does show how Spin project can be built.
msrobots did a lot of work with that compiler and created a fully working IDE in the browser, Editor17, that looks a bit like the Proptool with similar syntax highlighting, it keeps all it's files on the web site. You can try it out here: http://parallax.msrobots.net/Editor17.htm
Finally I have to say, my idea of "cloud" development is that my code exists in many places. Repositories in github, local repositories, repos on test and live servers. The editors or IDEs can be local or remote. Deployment can be to google or AWS or whatever.
The point is not to become dependent on a single cloud provider. You never know when you might need to take your work else where. As the recent sourceforge scandal shows.
The 'big' version is an enterprise-sized 'data-lake', 'data-analsys', 'data-visualisation' solution I am involved in - with Hadoop at the centre and an ever-incresing ecosystem of tools and subsystem around it. It needs to be a co-develop globally solution, and will reside in a cloud, e.g. Amazon Cloud. This kind of big scale system is too far from my expertise for me to elaborate.
The other - which by coincidence landed on my home desk yesterday (kickstarter) is an IoT cloud solution, 'Viper' (Python & VM) for Spark Particle and other (hw): https://www.kickstarter.com/projects/1322607643/viper-the-python-iot-design-suite-for-arduino-udoo/posts/1273794
It is easier for me to understand this one. For Spin I have been using Google Drive as my 'cloud', but it is really cumbersome, and since I alternately work offline and online, to manage the synchronisation is messy. With the Viper cloud service uptodate libraries, VM software, etc. is readily available, and to synchronize my files is just about clicking the cloud button. It looks
good, and I am looking forward to test and learn, I just need to receive the Particle board.
I am sorry to say that all this does make the Spin environment look a bit 'tired'.
Erlend
These are interesting times.
I recently attended a full day presentation gig by Amazon on their AWS services. They have so much on offer its hard to know where to start. We will be hooking up with a consulting company next month to analyse our requirements and set a direction. What turns me off all of this though is the thought of becoming reliant on a single vendor by making our systems dependent on their "special source".
In the meanwhile we have a smart young guy who throws all the data from our remote devices into some data bucket on Google cloud services. I don't even know what it is yet but the API he created to get stuff in and out works well and the data grows bigger every day....
There are plenty of people trying to get control of your Internet of Things things. Viper is a new case I had not hear of. There is resin.io, Electric Imp, Microsoft with its Windows 10 for IoT and many others. These same lock-in issues worry me about all of them.
Personally Viper is a turn off due to it's use of Python, the need for some app to be installed locally the requirement for a mobile phone app, the need for special hardware. No, I want my things to deal with some cloud service using open protocols connecting to server parts that I can find elsewhere and with web based interface that works anywhere that has a browser. Ah!, you have been seduced by shiny mobile apps and web consoles!
Thing is the Prop is not an Internet of Things thing. No more than a 555 timer or 8 bit Ardunio. Not without some help from an external device that provides net connectivity and can reprogram the Prop.
I can imagine though that Spin development could be done from any web browser anywhere. As Spine and Editor 17 demonstrate. It just needs a service in the cloud to maintain the files. Compiled code could be pushed back down to a little server running on a PC or Pi or whatever that then programs the Propeller. If you happen to be using Chrome OS or a Chrome browser then that Chrome app can program the Prop directly, same as the Prop tool does.
Not long ago Parallax was keen to get this kind of thing in motion. That initiative seems to have gone quite recently.
Similar to what you mention we are hooking up with an Hadoop-centric consultant, but more as a facilitator. Similar to your worries, we worry about being locked in. Our hope is that by selecting Open Source technology - like Hadoop - we will not really be locked in. Not like in the old days when we implemented SAP - that was being locked in and the key thrown away. But still, the Accentures and Amazons of the world, they still have business models to be aware (wary) of, and I suppose the temptation to lock in customers will always be there.
On the private side what I do has no commercial side to it, so being locked in to e.g. Viper is not such an issue - I can ditch them any time. And honestly, right now I am locked in to Propeller because it has the Cogs, Spin, and this fantastic Forum.
I chose Viper exactly because of Python, because my objective is to learn Python, and if that can be driven by embedded projects I know that it will be more effective than for me to learn by writing non-realtime software.
I do not think I have been seduced by shiny mobile apps, but I absolutely have been seduced by the prospect of developing Spin anywhere, with possibly my target Propeller being connected to the internet somewhere - if it is to my home pc, fine, it does not need to be IoT-like.
If Parallax makes this available, I am ready to buy.
Erlend
I initially used (and still use for some projects) DropBox for my Spin files.
Heater finally convinced me to use GitHub and I'm switching over to using GitHub for my personal projects.
I have some work projects which I need to keep private and these projects reside in a shared DropBox folder which my client can access.
I'm debating upgrading to a paid version of GitHub so I can keep private (work) projects there. I also think GitHub would make it easier to keep track of who changed what in a file. I don't have a good system to track what changes the client may make in a file when the file is in the shared DropBox folder.
I doubt I'm using GitHub to its full potential but even with my limited knowledge of how to use GitHub, it has already made a big improvement in the way I keep track of revisions.
I found a surprising benefit to having stuff in a public git repo. It kind of makes you self conscious about your code, even quick hacks. Know that other people might look makes you spend that little extra effort in neat formatting, commenting, readme files, not throwing in messy code. All of which is great when you go back to some code a year later.
I don't have much, if anything much useful to others in my git repo https://github.com/ZiCog but I was amazed to find people actually sending bug fixes, raising issues, and starring projects.
About Github; I definitely recognize the effect that would have - that I would strive to make the code 'presentable' before sharing with everyone. I might be my next step, but for now I have little code at that level, I think.
Erlend
I see people say this a lot around here. And the code never gets cleaned up, and never finds its way on to GitHub or any other repo.
I would strongly encourage you to start using Git now, before you "clean it up". This has a number of benefits:
- All the standard benefits of any version control system
- Having a history that clearly shows what steps were taken to clean up your code can help you and others learn from past mistakes (this has been a ton of fun for me, looking at how horrible old versions of PropWare were. And I look forward to looking back at today's version of PropWare a year from now and repeating the process)
- When (not if) you mess up your refactoring, you'll have a clear history to help you figure out what was refactored (cleaned up) incorrectly
- If using GitHub, BitBucket or another public repo: When you have a question about how to clean up a certain snippet of code, sharing is easy because you say something like:
Notice that reasons 1-3 have nothing to do with a public repository. You could use a local git repository, a private repo on github (small fee) or bitbucket (free) or your own server for hosting and get 90% of the benefits very easily."I don't like how long my put_float function is. Does anyone have recommendations for improving legibility?"
I agree, if you have any project that you think you will be working on in future or you think others may be interested in, stuff it into github (or a local git or where ever as soon as possible). For sure if it's a public repo you will feel the urge to clean up your act soon enough
Erlend
So far this has been a bad experience. I really get put off and in a bad mood when I hit a brick wall user interface. The Windows GitHub is horrible, the git CLI requires me to md, cd, and type in long filename paths, something that I used to do in the previous millenium. The web GitHub interface seems ok, but even after having read numerous GitHub tutorials I am still not up and running.
Just look at my acid posting here - GitHub did not make my day today. Maybe I will try again some other day, but it reminds me of the early days of MS Word - when I had some good ideas and started typing them down, but had so much frustration with formatting bugs that all creativity and ideas were pushed away by MS agressivity. I learnt to type stuff down in raw text in simple robust text editors.
Erlend
Sorry to hear you are having a bad github experience.
I have no idea about any Windows GitHub client or any other GUI client. I only ever use git from the command line.
I'm curious as to why you are having such a hard time with the command line interface. I'm not sure why you are having to do so much typing of long file names and such.
I just looked back through the history of past few weeks using git on a project and I see I generally use a very small subset of git commands and options. Things like:
$ git pull
$ git diff$ git status$ git push
They never require typing in as generally they are sitting in my command history, few hits of "up arrow" gets me the one I want then I hit "return". Besides they are very short anyway. Easy.
Things like:
$ git diff src/app.jsx$ git add src/app.jsx src/three-test.jsx webpack.config.js
are a bit more heavy going but generally those file names are never typed in. Either I get as far as "git diff s", hit "tab" and it becomes "git add src/", type "f" and hit tab and it becomes "git add src/floater.jsx", now hit "enter", job done, Easy. Tab completion is a wonderful thing.
Or file names are just highlighted with the mouse from wherever they appear and a click on the centre mouse button drops them into the CLI. No typing required.
Then there is:
$ git commit -m "Disable UglifyJs for now, it does not work with ES6"
Well, again the command comes from the history buffer. The actual commit comment is text that you have to type somewhere no matter what tool you use. Easy.
Given that one might be spending hours typing and editing code, those few keystrokes to operate git are negligible by comparison and take only a few seconds.
All in all, rather than being "previous millenium" I believe some things, like git, are only made harder to use with GUIs. My editor here is very GUI. With syntax highlighting, red squiggles under sytax errors and so on. I could drive git from it but I don't see the point.
By the way I have had to use many source management systems overs the years. All universally horrible, including Visual Source Safe, Clear Case and so on. Their GUI interfaces did not help. Git is the most pleasant version control system to use ever and has a lot more powerful features if you need them sometimes, which is why I suggest it. GitHub is the icing on the cake.
I hear you loud and clear if what you're saying is "this is too much overhead for the payoff!" It's a new tool - it might take you 3 hours or a whole day to learn it. It could save you an entire week someday.
If command line isn't your thing, I have a few suggestions.
- PyCharm.
- Eclipse also has the EGit plugin... but I'm far too biased against Eclipse to ever recommend it :P
I'm glad you already installed GitHub's client though - it comes with the command line tools which are good to have. Odd as it may seem to me, none of the tools that I just listed include the command line client.This is 1000x more power than you need, since it is an entire IDE, but their user interface is very intuitive and their diff view is magnificent. Unless you're looking for an IDE (or already using CMake) this probably isn't the option you should go with
When it comes to the "this is too much overhead for the payoff!" I must admit I had much the same feeling on meeting git for the first time years ago. All those commands, all those options and switches ouch. And the documentation available then although complete did not really point out that minimal set of simple operations one would be doing most of the time.
Then cam github and lots of simple tutorials and docs. I hope the effort required to get in tune with git is a lot less. The pay off is definitely worth the effort.
Erlend