I was pleasantly surprised to find that pyinvoke code worked perfectly for running some tests for me. This will make my CI testing more complete.
from django.test import SimpleTestCase
from invoke import run
return run("cd node-app && mocha")
A little advice for you, and it might seem just a little nuts, but I think you’ll thank me in the end.
When you start making your app (now just to be clear here, I mean an app that is intended to go on the Apple, Google, or Windows app store), start by making a dummy app and immediately put the app on the store.
Google and Android both have beta programs that work excellent. You can make incremental updates as you develop it. Using the beta programs can get you feedback quickly and help you to focus on creating the essential parts of your app.
Windows might have a beta program you can use on their app store, I haven’t gotten there yet. They *should* have one.
One of the most wearying parts of making an app is cramming your time into it and just when you think you are done… Dang it! Forgot to make a hundred icons and feature graphics.
Publish to the app store first and use the beta programs.
I finally got my CYOA fairy tale adventure in beta.
Give it a try and let me know what you think
Thinking in terms of web components is a little tricky. How am I supposed to handle all the ways an element can be abused? I don’t think I can, and even so, I’m probably to lazy to try.
I just need a simple REST API:
- To be able to handle individual items in a collection (Add/Remove/Interact)
- To be able to list the whole collection
Man, makes me think back to the Backbone.js collections. They were super easy to work with. Should I just create an element in the global context and let the individual elements deal with it? That doesn’t seem to be as composable, since then you couldn’t have two of the same rest api could you?
I thought of the following ways to handle these requirements:
- Make a global rest-api context that can be named. Naming them will avoid the first problem of composability. It still doesn’t seem to be the web component way though
- Make a global rest-api and have the elements reference them via a “source” attribute
- Make a global rest-api and communicate with events
- Make a local rest-api per element
There are too many ways to do this!
Making a local rest-api per element seems like it would lock you in to an api structure, or barring that would force you to proxy attributes and I don’t want to do that.
The global methods sound better to me, except that they are global. Maybe that isn’t a big deal, after all the datasource is pretty much global too.
Which of the global contexts would work the best?
If a use a named or unnamed rest api on the global context, then I’ll have to add an attribute to the children to tell them what rest api to connect to. That seems like something I’m not going to be able to avoid. Event the events would require namespacing.
Using a named source is kinda how I think the Polymer app storage thing works, and it will work for events or “source”ing. I think that might be the way to go. If database needs to be able to switched out when I find something better. Naming the sources and the elements that use the source will probably be the easiest to change.