I'm hoping this is a no brainer. I've been doing iPhone development and have been asked to develop an iPad app for internal company use whereby 2 or 3 iPads in close proximity can talk to each other.
The following description isn't really necessary but I just want to solidify what I mean by "talk to"
Conceptually: three people, each with an iPad, each iPad having the complete listing of e.g., both all UPS packages that arrived/will arrive in the morning delivery totaling 500+ per delivery and an internal hot list of packages that when they arrive must be immediately delivered. Each of the three people continually grab packages, and select their package from the UPS list. Other stuff is entered like who gets the package, which internal bin the package was placed, whether on the hot list, etc. but the key is that all information has to be current in real time (+/- a few seconds) on all iPads participating in the package grab.
With the features that the iPad has, what's the best way to make this possible?
Thanks
Using the gamekit apis will be ideal
I'd write an app that uses Zeroconf/Bonjour to discover other instances of the app running and send XMPP messages around.
Related
I am making a stock market simulator website for an event. It will be an event where about 200-300 people will participate as investors.
There will be 3 databases, one for all available stock (Industry, Company, Price etc.), one for all investors (Name, Stocks Owned etc.) and one to store all trades that happened. It also needs to run fast as transaction related calculations need to happen quickly to avoid any conflict with other investors.
I have the website written in React, but I'm not sure about what to use for the backend. I was going to use a python framework with firebase, but I think this would be too slow as it is an app that needs to be working live. Also, any pointer towards a good architecture to use would be nice too! I was thinking a basic microservices architecture (without actual RestAPI's but just file calls as this increases hosting cost), but I'm not sure if this would be the best for my use case.
Any help is appreciated!
I have developed a program using curses, everything is cool so far but I was wondering myself if there is a good pattern to split different views/panels of my program into smaller chunks callable by my main loop?
Further informations:
This program is a rather small automation tool/wizard aiming to ease our application for customers requiring the on-premise installation.
This wizard is a 3 steps one and it’s used to grab informations from our customer installation needs depending of it’s chosen architecture.
The first step is requesting the customer to give us its identification informations such has contract number, company name, licence number and preferred contact.
The second step is requesting the customer to give us informations about either he want a standalone installation (All-In-One install) or a N-Tiers installation plus the required informations like the requested custom SSL VHostName or Tiers IP/Credentials.
The third and final step is showing the customer a progress bar and informations of the required services (MySQL/HTTPd/HAProxy/PHP-FPM) and our application.
I know that I do not especially need to use curses library for such a program but our UX Team requested it as it is part of our customer experience with the solution.
You can look at the Forms library. It's a nice extension to ncurses that allows you to better manage input forms like yours. It offers a simple function interface to read the fields, change their properties, etc., as well as many different field types (including regexp-validated fields). In your case, you can simply create three forms, and post/unpost them in succession.
as such way to do things is not really usual, do not expect any framework to be available (like those available for WebUI for instance).
I so decided to create my own "Framework/factory" and so to be able to split every aspect of my app in a logic that would be similar of those used by web applications.
The source-code is dirty and really not pythonic, but it is well working so far and quite easy to maintain.
Thanks everyone for your answers and ideas.
I recently launched a fantasy football online game for the English premier league called Myfpl11.com and I want to know what server should I choose if I am expecting 20k visits a day. My visits are going up and I want the site to keep performing smoothly. Please help.
This is probably the wrong area of StackExchange to ask this sort of question. However ...
The first thing you should do is get prepared to scale horizontally instead of vertically. If you keep growing you will soon grow out of any single server that you purchase.
Instead, what you need to do is start looking at ways to modify your website to be able to work over multiple systems. If you're experiencing load issues on the server you currently have, spin up another one of the exact same instance and move the database to that server, so you will then have two -- one dedicated to the database (which will really help it do its job) and one dedicated to serving traffic.
From there look at how you can scale in to multiple web processes, databases and add caching layers.
You can add cloudflare.com as your DNS service which will help you out by better caching your assets, but most importantly they will deliver a technical issues page to your users if your site does fall over at any stage. This is really helpful for saving face, because they will get an actual page with a message instead of a continually loading white-page.
Look at using services like digitalocean.com or linode.com (both very affordable and great staff) where you can easily add/remove resources as you need them.
I'm building an app, with Sencha Touch and NodeJS as a backend. This app is supposed to be used to control and report the whereabouts of public transport in a city. I'm planning to have three modules built, one for the passenger, one for the driver and one administrative module.
What I'm thinking is, should I build all these modules in the same app and check for user profiles at log-in? Or should I build separate apps (at least to separate the general user module from the other two) to make it more secure.
If the passenger somehow got access to any of the other modules it would obviously be extremely harmful.
The first reason to have 3 different modules is what you have pointed out - security.
The second reason to do so is - what if one of the services fails - as 1 large codebase it brings the whole lot down - as 3 different services, 66% of your service is still working.
The third reason is KISS - keep things simple stupid - one big codebase is harder to reason about and model. Bugs affect the whole codebase. Adding features becomes a trade off between the services.
Generally I would say to not only split your app into 3 modules but to take this approach down to a much lower level and try to split things into 'single components' as much as possible.
Think about a carpenter making a table to order (what most software devs are doing is 'to order').
The carpenter does not download a 'table making' library as one large codebase.
They first use the 'saw' program to saw wood.
Then the 'sanding' program to smooth wood.
Then the 'Hammer' program to put wood together - etc etc
Notice how each step is one tool doing one job.
The next day the carpenter is asked to make a chair - they use the same tools in a different order.
This is the Unix Philosphy
I would say that dividing the access to different information is an application layer concern and I would build it all into the same node.js app. This app should check with the user permissions if that type of user has access to the information it is requesting.
If I understand correctly, companies like McDonalds and Apple have or will deploy large numbers of iBeacon BLE devices at their stores, each presumably having a unique UUID so that triangulation is possible within the store. Is there now, or will there be, a central place where UUIDs for various stores are going to be made available for bulk download for people who want to use them in apps?
Actually, the range of UUIDs for a given organisation will be quite small - 1 or maybe 2. It is the 16 bit minor and major values that are associated with a given UUID that identify a location.
An app can register its interest in a limited number of UUIDs (the total number of UUIDs that can be registered across all apps is also limited, so it is best for an organisation to use as few UUIDs as possible)
Once it has registered interest in a UUID, the app will be notified when the device comes into range of one. The app can then display an alert to the user prompting them to enter the app. If they do, then the app can retrieve the major and minor numbers from the beacon. The app can cross reference this information against a database, possibly via a web service, to determine its location. For example Major=12 might mean Sydney Apple store, minor=4 might mean the Genius bar.
If the device is in range of several iBeacons then it can use signal strength to estimate a range and therefore a location, but it isn't really triangulation in the true sense.
As to whether companies will release details of there UUIDs, major and minor values is unknown and will certainly vary from organisation to organisation - the data is being transmitted in the open so it is possible that 3rd parties may gather this information and make it available.
Locate for iBeacon (iOS) and iBeacon Locate (Android) can optionally collect iBeacon data and upload it to WikiBeacon.org, a public directory of iBeacon Locations. Data collection has been going on for a few months, but the directory has not yet been launched. I will update this answer when in is available.
If you know of the locations of iBeacons that you would like to be included in this directory, you can enable data collection in these apps, then use them to scan for them.
Data of this kind relies on reports from individual app users, so it is not comprehensive. Many organizations deploying iBeacons have no incentive to publish their locations because of the expense involved with deploying and maintaining them, so they probably will never reveal this info.
Full disclosure: I am Chief Engineer for Radius Networks.
The fact you don't know iBeacon identifiers (mainly UUID) for already deployed beacons can be indeed problematic. Basically, it does not allow you to leverage existing infrastructure for your applications and forces everyone to build their own infrastructure (= duplicate iBeacons), which is inefficient both financially and "morally".
We have started an effort called OpenUUID to help fix this issue:
OpenUUID
Basically, OpenUUID is a free to use registry of unique proximity UUIDs for your iBeacon applications.
Help us clean the iBeacon environment by using it to generate your proximity UUIDs and by spreading the word about this activity, so that McDonalds or Apple use the OpenUUID service for their iBeacon deployments... ;-)