Me and my team will be developing a POS system for a restaurant chain.
In addition to a windows application for the POS, the main idea is to make a native (not HTML5) mobile application that will help in tracking orders.
The mobile app should do this -
1. Waiters will take and track order.
2. The manager should be able to check employees's leaves,timings,etc.
On the POS part -
We are thinking to make a particular restaurant work with its local database that will get synced with the central database.
Are we on the right track?
Can HTML5 help us in the mobile application?
How many do you willing to pay for me to give you the architecture? Just kidding.
Think of a retailer that:
Has only 10 kind of items
With sell only 5 quantity of each items each day
That has only 1 staff and it is his/her family
That sell only with cash and not electronic payments
Do you think that kind of retailer need a mobile application which can do POS with cloud computing support? Of course not. He/she maybe only need a book written manually with simple accounting debit credit to track his/her income/expense. But a big company like W*lmart will do.
If you want to make an application, make sure that you has the requirement. Why bother create something that is not needed?
If you want to make a general POS application, collect the basic requirement first. What they need. Will they do input by entering the item code, or scanning using barcode? Will they need to make a payment after the item being entered (typical retailer system), or they need to make a payment after they asked for the bill (typical restaurant system). It will later decide your architecture.
Now asking your question:
In addition to a windows application for the POS, the main idea is to make a native (not HTML5) mobile application that will help in tracking orders
As I have have said before, the architecture will depend on the device used and how the process be done.
The mobile app should do this -
Waiters will take and track order.
The manager should be able to check employees's leaves,timings,etc.
First point is your requirement but 2nd point. What? Track employee's leaves, timings,etc? It should be included in HR module, not POS module. Keep your application scope to the smallest and make sure that each of your module are in same topic.
On the POS part -
We are thinking to make a particular restaurant work with its local database that will get synced with the central database.
Try it and you will know whether this distributed database design are good or not. Search for articles about pros and cons for this design and make sure you know the sequences before starting design.
Are we on the right track? Can HTML5 help us in the mobile application?
It is like a same question as: Can a keyboard help us type? HTML5 is a language used in any web - server programming. It is kind alike of rendering / layout technique. If you want to aim for modern browser such as latest version of firefox, then go for it. But really, do you know how HTML5 can help you, or do you know what are the downside of using HTML5?
Since this app will only be used by employees of the restaurant,
(not by customers), it would be safe to assume targeted mobile
platform, Android or IOS.
Since, the inventory, employees leaves etc is being tracked in
restaurant locally, the idea of using local DB which syncs with
the remote DB seems the right approach.
The menu of items and their codes should stored at central DB
server and fetched from there.
Related
I'm working for a startup and we have a customer who uses Demandware for their online store.
Our company provides vouchers which are worth a specific amount of money. So customers on the retail site can enter the voucher number near the end of the checkout experience and if it's worth, say, 10 dollars, their shopping cart is updated (-10).
I have the CTO saying we just need to "drop a few lines of javascript" onto the retailer online store. But I think this requires a Demandware plugin (especially updating a shopping cart), which involves signing up for a developer or partnership account (which takes some time), learning Demand Script and building the plugin, then releasing it to Saleforce's app store. Am I correct? Is this the only way to achieve this?
Just to be clear, the functionality is: the voucher code box needs to take a voucher number, an API request is made to our service to check what it's worth, then update the cart.
That's a pretty broad question but I'll try to explain.
First off, Demandware has gone all JavaScript.
But yeah, it has a huge API so the process sounds about right the way you've described it.
Ask your client whether they have a service integrator they're working with, because that would be their job. Your job would be to provide an API so that Demandware can check whether the voucher code is valid.
Demandware is a closed community so it's unlikely to learn it unless you're working in a company that is doing Demandware development.
Oh, and if it somehow ends up being your job to develop this, a tip from me - you probably need to get access to their site's files and use the LineItemCtnr class to createPriceAdjustment() :)
The first tip from me is that Demandware got bought by Salesforce and is now branded as Salesforce Commerce Cloud, so if you hear either, they are the same thing.
You are right that you are going to have to work with Salesforce to get going. They are a cloud provider and there is no self-hosted version of the platform, so in order to do any development, you need to have a relationship with them.
So then it depends on how you get access. If the client has any sandbox environments they are willing to share with you, you could do this as a custom build working in their environment, modifying cart code to make the service call as you ask and as the previous response suggests. But then (depending on the terms you have with the client) your company may or may not be able to reuse that code for other clients. You will also have to work with them to get that integrated into their existing site, get it deployed through their processes, etc.
If you want to write something that other Commerce Cloud clients could use, then you should set up your own partner relationship with Salesforce and get a software package they call a cartridge to what they call their LINK marketplace, which is basically a big clearinghouse of integrations like yours.
Technology-wise, the platform has gone through some changes recently, going from an XML-based GUI tool to specify business logic to using CommonJS scripts to define them. If your client is a new client within the last year or two they probably have this new fully javascript implementation, but if they are an older client than that they may be using the old way, which has a steeper (read: more proprietary) learning curve.
I'm planing to make android app the need of it is to recognize building in the city .
I need help in choose the most important unique features in the buildings ,such that the size of the features stay small as it will not be a practical application if the size of the database become large , is running the application offline possible or i should send the features to remote server for processing the similarity between the pictures ?
Actually, you could choose some simple but effective features(building logo, the foreground of the building) for recognizing offline.
In order to make the result more accuracy, you cound send the GPS information back to the server.
Do not only recognize the building by analyzing the picture, sometimes ,you can get more information from the Android.
Good luck.
Ok, so about a year ago I wrote a web app that helps organize appointments for my dads company. He now "couldn't do business without it". I have decided that I want to build a SAAS subscription model out of it and open it up to the public.
It's currently built on codeigniter and php which I do not think is a good fit for a SAAS version. I am planning on rebuiling it from scratch in laravel 4 and using stripe as a payment gateway.
My concern is how best to handle the database / application structure for more than one client. Currently, it just serves the one business and is very un-abstract and is specific to my dads companies needs. I need it to be able to handle different data depending on what the business who uses it does.
I have looked into multi-tenancy but i'm not sure this is right for this. I am thinking that a 'gmail' style approach would be better. One app / domain that after login the user will see their customised dashboard and only their data.
Before I get stuck in with the coding I need to work out how best to handle multiple 'accounts' on the one database. I do not want to create a table for each user, nor a database for each user.
I guess my question is can anybody point me in the right direction for how best to handle a monthly payment subscription in Laravel? It's not so much the code that I'm stuggling with, rather what exactly I would need to build to handle charging the customer each month and denying them access if billing failed etc.
Thanks
You are in for a lot of reading and a ton of work!
First of all, let's completely ignore the billing aspect of this for now — at the end of the day that portion of the application is really fairly trivial. Take a page out of 37signals Rework (page 93 and 94) and launch your product with a 30 day free trial before you even begin implementing it (you should know how to implement it by then).
Second, why do you think that "gmail" doesn't use multi-tenancy, URI structure tells nothing about the underlying database structure. I'm fairly confident they aren't cloning a database schema for every one of their customers. Therefore you've probably answered your own question — you want to implement multi-tenancy.
You're going to want to abstract your database (and application architecture), and honestly there is no better resource to help you on your way to doing that than Taylor Otwell's (creator of Laravel) book Laravel: From Apprentice To Artisan. His book is not for beginners, and by the time you're done reading it you should probably be able to answer this question for yourself.
You are not going to be creating a table or a database for each user, you aren't even going to be creating one for each organization. Instead you'll be creating abstract database structure in code, which will pull your users data out of the database.
Think about checking for permission to access an organization as another layer of user authentication. On every request you'll be checking to see if that user can access a particular organization. You'll likely also check to ensure that organization is still active (did it expire because they didn't pay?) this will again happen on every request and likely with a filter within laravel.
This really leads to the next very important factor of developing a SaaS application.
I don't know about you, but I'm paranoid, and I couldn't sleep well at night if I wasn't sure that user number 4506 couldn't see the data of an organization that he doesn't belong to. The only really good way to ensure this is through unit testing, which I'd highly suggest learning if you haven't already.
The best way to do this within Laravel 4 is to read Jeffrey Way's book Laravel Testing Decoded. This book is extremely advanced, but still easy to understand if you have a good grasp of the fundamentals.
Last but not least, the number one thing is get involved in the community — the easiest way I'd suggest doing that is idling on the #laravel IRC channel (freenode). Ask some questions, maybe answer some questions, everyone in the channel is very nice and responsive.
You are definitely in for an adventure, don't be afraid to ask questions and make mistakes. Good luck.
As a rough overview, I would have a clients table, and a subscriptions table. Any other data that needs storing such as contacts, or appointments, can be associated using foreign keys to the client table.
In laravel, you can use the ORM to get the currently logged in client, and then through a relationship, fetch appointments and contacts belonging to them.
There are some useful tools for laravel at cartalyst.com, including sentry and sentry-social for user auth, and integrating user accounts with facebook/google/twitter, etc.
Stripe will allow you to configure recurring payments, and will notify you via web hooks each time there is a payment attempt. you can log these in the payments table, and associate them with a user/client. you can use this to keep track of who has paid, and how recently.
Also, bear in mind that you may not want to cancel the account immediately on failed payment.
Stripe will reattempt, and it may be that your best response is after it is two or three days late, or you get an invalid card notification,to get in touch with the client and prompt them to update their payment details.
It may also be an opportunity to check when they last logged in.
If it was over a month ago you can credit them with a free month, and remind them of how much your app can do for them.
By doing this, you may be able to get people to continue using (and paying) for something they had forgotten they had subscribed to.
I searched but couldn't find a proper answer for this...may be I didn't look deep enough. Anyways, little insight from you guys will only make things easier. So hear me out.
this is for my final year research project. I just need concepts and if any links I can read more.
So this application is a distributed one for a hotel which has 3 branches (including the main hotel) in location A, B, C.
I & (my colleagues) have developed the database, business logic, and 3 separate GUIs for the billing, bar and the kitchen. All are working perfectly and we used .NET remoting for this. this is the whole system and GUIs connected to the business through LAN.
This system, should be deployed in each location (A,B,C) and from the main hotel (A), I should be able to view the details of other locations (B,C). and all 3 systems should be connected through the internet.
problem is, how do I do that?
I just wanna view the information of other places and may be take printouts. that is not relevant for the question i guess.
The database is not distributed, each location has its own database. If I were to use a web service, how can I do it more cost-effectively? where do I have to deploy the service?
as a side note, I have developed a simple chat system (remoting) and tried to connect it through internet with a friend but it didn't work. If anyone knows why?
please be kind enough to provide any other relevant information on this topic. and please ask questions.
Why not just build a web application with a secure login? That way you build one system, deploy one system, maintain one system. All your data would be in one place, making reporting a lot less onerous, the whole thing would be faster and if you ever need to add a fourth, fifth or twenty seventh additional location, then you'd need to do very little to make it happen.
I see no reason why you have to go about it as you are.
Screen scraping seems like a useful tool - you can go onto someone else's site and steal their data - how wonderful!
But I'm having a hard time with how useful this could be.
Most application data is pretty specific to that application even on the web. For example, let's say I scrape all of the questions and answers off of StackOverflow or all of the results off of Google (assuming this were possible) - I'm left with data that is not very useful unless I either have a competing question and answer site (in which case the stolen data will be immediately obvious) or a competing search engine (in which case, unless I have an algorithm of my own, my data is going to be stale pretty quickly).
So my question is, under what circumstances could the data from one app be useful to some external app? I'm looking for a practical example to illustrate the point.
It's useful when a site publicly provides data that is (still) not available as an XML service. I had a client who used scraping to pull flight tracking data into one of his company's intranet applications.
The technique is also used for research. I had a client who wanted to compare the contents of several online dictionaries by part of speech, and all of these sites had to be scraped.
It is not a technique for "stealing" data. All ordinary usage restrictions apply. Many sites implement CAPTCHA mechanisms to prevent scraping, and it is inappropriate to work around these.
A good example is StackOverflow - no need to scrape data as they've released it under a CC license. Already the community is crunching statistics and creating interesting graphs.
There's a whole bunch of popular mashup examples on ProgrammableWeb. You can even meet up with fellow mashupers (O_o) at events like BarCamps and Hack Days (take a sleeping bag). Have a look at the wealth of information available from Yahoo APIs (particularly Pipes) and see what developers are doing with it.
Don't steal and republish, build something even better with the data - new ways of understanding, searching or exploring it. Always cite your data sources and thank those who helped you. Use it to learn a new language or understand data or help promote the semantic web. Remember it's for fun not profit!
Hope that helps :)
If the site has data that would benefit from being accessible through an API (and it would be free and legal to do so), but they just haven't implemented one yet, screen scraping is a way of essentially creating that functionality for yourself.
Practical example -- screen scraping would allow you to create some sort of mashup that combines information from the entire SO family of sites, since there's currently no API.
Well, to collect data from a mainframe. That's one reason why some people use screen scraping. Mainframes are still in use in the financial world and often it's running software that has been written in the previous century. The people who wrote it might already be retired and since this software is very critical for these organizations, they really hate it when some new code needs to be added. So, screenscraping offers an easy interface to communicate with the mainframe to collect information from the mainframe and then send it onwards to any process that needs this information.
Rewrite the mainframe application, you say? Well, software on mainframes can be very old. I've seen software on mainframes that was over 30 years old, written in COBOL. Often, those applications work just fine and companies don't want to risk rewriting parts because it might break some code that had been working for over 30 years! Don't fix things if they're not broken, please. Of course, additional code could be written but it takes a long time for mainframe code to be used in a production environment. And experienced mainframe developers are hard to find.
I myself had to use screen scraping too in a software project. This was a scheduling application which had to capture the output to the console of every child process it started. It's the simplest form of screen scraping, actually, and many people don't even realize that if you redirect the output of one application to the input of another, that it's still a kind of screen scraping. :)
Basically, screen scraping allows you to connect one (web) application with another one. It's often a quick solution, used when other solutions would cost too much time. Everyone hates it, but the amount of time it saves still makes it very efficient.
Let's say you wanted to get scores from a popular sports site that did not offer the information available with an XML feed or API.
For one project we found a (cheap) commercial vendor that offered translation services for a specific file format. The vendor didn't offer an API (it was, after all, a cheap vendor) and instead had a web form to upload and download from.
With hundreds of files a day the only way to do this was to use WWW::Mechanize in Perl, screen scrape the way through the login and upload boxes, submit the file, and save the returned file. It's ugly and definitely fragile (if the vendor changes the site in the least it could break the app) but it works. It's been working now for over a year.
One example from my experience.
I needed a list of major cities throughout the world with their latitude and longitude for an iPhone app I was building. The app would use that data along with the geolocation feature on the iPhone to show which major city each user of the app was closest to (so as not to show exact location), and plot them on a 3D globe of the earth.
I couldn't find an appropriate list in XML/Excel/CSV type format anywhere easily, but I did find this wikipedia page with (roughly) the info I needed. So I wrote up a quick script to scrape that page and load the data into a database.
Any time you need a computer to read the data on a website. Screen scraping is useful in exactly the same instances that any website API is useful. Some websites, however, don't have the resources to create an API themselves; screen scraping is the developer's way around that.
For instance, in the earlier days of Stack Overflow, someone built a tool to track changes to your reputation over time, before Stack Overflow itself provided that feature. The only way to do that, since Stack Overflow has no API, was to screen scrape.
The obvious case is when a webservice doesn't offer reverse search. You can implement that reverse search over the same data set, but it requires scraping the entire dataset.
This may be fair use if the reverse search also requires significant pre-processing, e.g. because you need to support partial matching. The data source may not have the technical skills or computing resources to provide the reverse search option.
I use screen scraping daily, I run some eCommerce sites and have screen-scraping scripts running daily to gather product lists automatically from my suppliers wholesale sites. This allows me to have upto date information on all the products available to me from several suppliers and allows me to flag non-economical margins due to price changes.