I went through the Google docs for the Mirror API a few months ago and it mentioned that only developers with the actual Glass hardware would be able to test apps through the online sandbox. Google took the Mirror API out of its "testing" phase last week. Does this mean you no longer need an actual pair of Glass to test out apps or do the same restrictions apply?
That is partly correct. Anyone can add the Mirror API to a project using the API Console or Cloud Console. See also Issue #2 which was opened on this issue and recently closed by a project member.
"Testing" the apps, however, are still a bit tricky. Aside from reading the timeline using your same Client ID/Secret, you have no way to know that the card has been sent. And you have no way to know what the card looks like.
Using Glass is still the only real way to fully understand and appreciate the UX.
Related
I am deploying the WSO2 API Manager based on the published docker-compose available at:
https://github.com/wso2/docker-apim
I've been able to, with a little assistance get everything working as expected, apart from one thing that is troubling: I have no problem accessing Carbon, Publisher or the Store web applikations, however, for some reason, the Store is extremely slow to respond, borderline useless, often timing out or taking minutes to load a simple view. This makes working with the entire solution cumbersome and it will never be acceptable among the potential users.
Apart from setting up the IP-addresses for the components there's nothing changed from the published compose image. I've tried accessing it from various clients, down to using a web browser on the host and it's all the same. The Publisher and Carbon works flawlessly with no performance issues. Does anyone have any idea, I'm a bit at my wits end.
Cheers
My goal is to build an application that can dynamically monitor my Stock Portfolio (Stock Options actually). So, I am building my business logic in a TDD approach using C# on .NET core. I haven't much thought about the interface because the following is true:
1) My broker is ETrade so I will have to authenticate and use their api for my position information
2) I need this application to run from 9:30 AM - 4:00 PM EST Monday - Friday
As I am nearing completion of my 1st MVP business logic, I am now starting to think about where I will delpoy the final solution and hence I am seeking the community for feedback.
I have heard, but not worked much with Microservices (AWS, Azure, etc.) so I'm not sure if that is the direction I want to look. (Also, I have a tight timeline and don't want to have to learn too much to get this thing deployed - but I am open to any solution). Excluding Microservices and the Cloud I have considered the following:
a) "I could run the program from a Console application"?
(answer) I would have to either:
(a) get a dedicated server to do or
(b) try to ensure that I can leave a laptop running at home or something, blah, blah
(conclusion) Both are plausible decisions.
b) "I could run the program as a Windows Service"
(answer) I would have to either
(a) (same as above)
(b) (same as above)
(conclusion) Both are plausible decisions.
c) "I could run the program as a Web Site"
(answer) I would have to either
(a) (same as above)
(b) (same as above)
(conclusion) Both are plausible decisions.
c) "I could investigate The Cloud (Microservices)"
(answer) ???
(conclusion)
So, in closing, basically, given the requirements of up-time between those hours and I would like to be able to access the app from any internet browser. I have logic that needs to ping various endpoints pretty much every minute during market hours. So I am not sure how I would handle this using a Web Application because if (by chance) the browser is closed, the Web Application stops running and thus would defeat my needs! Does the cloud help here? Maybe I should just use a Windows Service and make my logs accessible on the web. Or I deploy the TraderBot in a Windows Service and also build a Web Application to receive real-time intel from the TraderBot Windows Service / Logs / and-or DB? Not sure, but I appreciate any knee-jerk responses you all have!
I really like to connect pieces of tech to solve complex problems. Though it's not that complex.
Solution 1: Cloud-based, specifically on AWS
Use AWS Lambdas(Serverless compute) to hit the API to get prices or whatever info you are seeking and then store it in DynamoDb(A NoSQL DB). Use CloudWatch Rules(Serverless CRON job) to invoke your lambda periodically.
Then SPA Single page application to view values stored in DynamoDb. It can be a static website hosted on S3 also.
Or
A mobile app can also serve the purpose of viewing the data from DynamoDb.
Solution 2: Mobile-Only
Why not build the app purely for mobiles like iOS or Android. Check here I've coded one app just to track the price of different alt-coins of different exchanges.
With the mobile-only app, your app will fetch the prices periodically(Using alarms API in case of Android) and will store in its local database(SQLite in case of Android) and then you can open the app any time to see the latest values.
More solutions can be thought of, But I think above are a good approach for solving this problem rather than buying a VPS or blowing your laptop all 24X7 #ThinkCloud
PS: Initial thoughts only, Ask more to enhance the solution... :)
I wanted to dive into the world of distributed systems, cloud computing, IoT, etc., and I gotta be honest, I imagined everything being a little more intuitive than it finally turned out.
I had a tiny testing architecture in mind, that I'd like to set up with Google Clouds and their services, but I am kinda stuck since I can't get my head around some concepts.
What I basically wanted to do (as a first step) is writing a simple java application that would run locally on my computer. This application should just generate random numbers and send those numbers somehow to the google cloud. On the cloud I wanted to define another java application that would manipulate those random numbers in some kind of way (it doesn't matter actually). Afterwards, the output should somehow get back to me of course. And actually, at the moment, I don't even care about how exactly. It could be somehow back to my local app (with some kind of listener, would that be possible?). But it could also simply store the results somewhere on the google cloud? Or maybe upload them to my google drive?
I guess you already noticed that - at some points - I don't even know what i want exactly, since I'm not sure of what is possible, and what not.
Could you provide me some help to get this set up?
The most important questions for me right now are:
Do I need to use a pubsub system, where my generated numbers are sent
to, and which then forwards this to the cloud app, that transforms my
data?
How do I get my data from the local app to the cloud services?
Would my data transforming app run on Google Dataflow?
Above I wrote "as a first step"... because later I would also like to send config files (for example in json format, or xml) to the cloud, and the
cloud application should transform those config files... if I get the
first scenario running the I guess this woul also be no problem
right?
Those are just a few of the questions that are on my mind currently. The most important ones I guess.
It would be a big help. Sorry, if the questions are not very precise, but I really need some kind of pointing into the right direction.
Thank you in advance!
I think it would be good to read up on some of the technologies you mention here:
Google Cloud Pubsub: Pub/Sub enables you to publish messages to a topic, and consume them in another place in the (Google) Cloud. You can see some different examples of publishers and consumers in the link. In your case you could for example write a Java application that writes random numbers to the Pub/Sub queue, where they will sit for 7 days to be consumed by another component (for example, Google Cloud Dataflow). To get started developing, you can find the SDKs here (there is a Java SDK).
Google Cloud Dataflow is managed service running Apache Beam pipelines to process your data at scale. You can learn about the different concepts here and get started designing your pipeline here. I suggest taking a look at some examples first though, which will make it more easy to grasp what is actually going on. Dataflow has a PubSub connector, so in your application you will be able to read from the topic you created before. In Dataflow you can for example multiply all your random numbers and write them to a certain sink (for example Google Cloud Storage, or even BigQuery or PubSub again).
Google Cloud Storage: is a cloud storage where you can put files, for example the output of your Dataflow pipeline. You will be able to manually download the files using the Cloud Console UI, or you can use one of the SDKs to download the output programmatically.
Hope this gives you an overview and some pointers to start. Whenever you are ready and have a more concrete use case in mind, you can start looking at some more components.
I am building a dashboard that will monitor production data, and am able to access this data via web services. The data changes every 1 minute, so I would like to have a page with 4 charts/gauges (the number of systems I am monitoring) that would get the data pushed to them with a successive web service call.
Can anyone suggest a good charting kit that would work well with C#? And would SignalR be a good fit here do you think? I have read that node.js and socket.io are options, but I have no experience with node yet. I would like something along the lines of DevExpress. Perhaps jquery and something on the front end works here as well? Thanks!
For such a dashboard SignalR is definitely a good fit if you already work with .NET and ASP.NET. For a web dashboard in particular, a good graphic library is Raphael, which is open source and pure JavaScript. It's simple and straight to the point, but often less is more. You can build interesting kinds of charts with it.
This project is maybe interesting for you as a sample of those 2 technologies together. If you press the skulls to raise errors, they will be triggered on a backend simulator and pushed to the dashboard using SignalR. You will notice a piechart graph there, which is done using Raphael and updates live when new errors are received.
The code of the project is here, it's a bit complex but maybe you want to have a look anyway. It's based on SignalR 1.x, but overall concepts are still the same.
At this moment we have a sneak peak GDK and there are rumors that final GDK will come by this summer along with a public google glass device.
Now, we plan to make our google glass app built on GDK and at this moment we can only use sneak peak GDK. So we basically plan to build app along with new GDK SDKs appearing so this summer we can immediately publish our GDK apps once Google starts accepting such apps.
How safe is that we start building using existing GDK? Can anyone confirm it will not be drastically changes so we don't end up in ever-changing loop?
I see that Glass guys are watching this tag so I hope someone of them can give us a direction.
[Disclaimer: I am another Glass Explorer and not a Google employee ... however I have experience in several large corporations involved in software.]
I would expect to have to make minor and perhaps major adjustments in any Glassware application development that we do. In fact, as we find anomalies or other inconsistencies, I would hope that our feedback and requests would actually help shape the initially non-beta released GDK. If we get into a "continually updating" cycle as the GDK evolves, so be it.
Just my opinion and expectation. We will focus on modularizing and hiding important elements so changes to match a new GDK can be contained.