Ask HN: How should I get started with Linux application programming?
7 comments
Is there a reason http://lemonpos.sourceforge.net won't work for you? The site is a little sparse but their blog http://lemonpos.wordpress.com is active.
I don't know anything about the lemonpos code, but they presumably have made and corrected their share of beginner's errors in the POS space, and you would save a lot of frustration by not repeating them :)
I had never heard of that. I'll check it out!
Does your client know you're asking about how to program their application on HN? It doesn't sound like you're particularly experienced, so maybe you should do them a favor and pass on this project.
I've made it very clear to them that I'm inexperienced. It's sort of an experiment for them too, as they have an existing POS but are just unhappy with it as they cannot customize it to their liking. I'm not charging very much, either.
Good point. On the other hand, if you've got some breathing room to see how practical it is, it's conceptually pretty simple. Start by finding out why they want to go Linux rather than using something like Quickbooks (which is not that expensive overall). Then start hacking something together with MySQL to see if you like it. I'd lean towards using python because it's friendly, but C remains popular on Linux.
There's a book called Beginning Linux Programming by Stones and Matthew which is a great introduction to the operating environment and key concepts, and nice to read. The use an example database application of a CD collection/music store, developed/extended in a variety of programming contexts and languages. I'd say obtain the book and curl up with it for 3 days, it's worth owning a copy anyway and you'll know after a few days whether tis feasible for you or you're entering a world of hurt.
There's a book called Beginning Linux Programming by Stones and Matthew which is a great introduction to the operating environment and key concepts, and nice to read. The use an example database application of a CD collection/music store, developed/extended in a variety of programming contexts and languages. I'd say obtain the book and curl up with it for 3 days, it's worth owning a copy anyway and you'll know after a few days whether tis feasible for you or you're entering a world of hurt.
Use Qt with C++.
Advantages:
1. Solid, stable, well maintained, well tested.
2. Great documentation, a huge library of code to learn from.
3. Batteries included. Web, databases, scripting, everything is painless and simple. Stand on the shoulders of giants, and stuff like that.
4. It's C++, so it's wicked fast.
5. Even though it's C++, it's not as difficult as people think it is.
6. Qt Designer makes designing GUIs simple and fun.
7. Cross platform. If you take care not to tie your app to any Linux-only APIs, you can make your app work on Windows and OS X by simply recompiling it on these platforms.
Pick up "C++ GUI Programming With Qt 4" and dig right in.
Of course, if you wanted to write Windows-only code, I'd suggest C#. If you wanted to write Mac-only code, Cocoa would be the way to go. Nothing beats native.
Advantages:
1. Solid, stable, well maintained, well tested.
2. Great documentation, a huge library of code to learn from.
3. Batteries included. Web, databases, scripting, everything is painless and simple. Stand on the shoulders of giants, and stuff like that.
4. It's C++, so it's wicked fast.
5. Even though it's C++, it's not as difficult as people think it is.
6. Qt Designer makes designing GUIs simple and fun.
7. Cross platform. If you take care not to tie your app to any Linux-only APIs, you can make your app work on Windows and OS X by simply recompiling it on these platforms.
Pick up "C++ GUI Programming With Qt 4" and dig right in.
Of course, if you wanted to write Windows-only code, I'd suggest C#. If you wanted to write Mac-only code, Cocoa would be the way to go. Nothing beats native.
Of course the first question would be about what kind of application you're programming. Is it a GUI program? If so use GTK or Qt. Is it a webapp? You have an almost endless amount of choices: Ruby on Rails, Python with Django, Perl with Catalyst, PHP with whatever
It's a point-of-sale, so I would assume a GUI would be best. Maybe not though? Why would a non-GUI program be an advantage for a point-of-sale application?
It could be a webapp, sure, but it needs to be able to print and interface with a printer properly... I suppose a custom style-sheet could take care of it. Do you think a point-of-sale webapp is a good idea?
And yes, I know I have a ton of choices, which is why I came here for advice. I respect and value HNs opinions.
It could be a webapp, sure, but it needs to be able to print and interface with a printer properly... I suppose a custom style-sheet could take care of it. Do you think a point-of-sale webapp is a good idea?
And yes, I know I have a ton of choices, which is why I came here for advice. I respect and value HNs opinions.
Being point of sale, it would be best to build a GUI app. Airports especially "still" use non-GUI apps (possibly due to the cost of upgrading), but it'd be far nicer for your end users to provide a clean and clear way to work with your application.
If it were to be a web app you could (for example) use a PDF library to produce receipts and handling printing that way. In this case, you could also provide a simple and clear way to customise the receipts.
Certainly the advantage of it being a web app is that you wouldn't specifically have a requirement for Linux (if for example they already have a set of workstations) or installed applications. This would mean that implementation would be far easier and say, managers could quickly pull up the POS system for a specific client in the back office.
The only issue I can see with a web app solution is interfacing with hardware. You would either need to forgoe the possibility of hardware, or work out a way to interface them.
I think there are countless possibilities, most of which will be rather dependent on the local businesses. They seem to have provided you with a lot of breathing space, so it may well be that many solutions will fit and you are free to choose which would work best for you.
If it were to be a web app you could (for example) use a PDF library to produce receipts and handling printing that way. In this case, you could also provide a simple and clear way to customise the receipts.
Certainly the advantage of it being a web app is that you wouldn't specifically have a requirement for Linux (if for example they already have a set of workstations) or installed applications. This would mean that implementation would be far easier and say, managers could quickly pull up the POS system for a specific client in the back office.
The only issue I can see with a web app solution is interfacing with hardware. You would either need to forgoe the possibility of hardware, or work out a way to interface them.
I think there are countless possibilities, most of which will be rather dependent on the local businesses. They seem to have provided you with a lot of breathing space, so it may well be that many solutions will fit and you are free to choose which would work best for you.
Maybe Qt is a good option.
I've always thought it'd be quite fun to make a POS system. I'd definitely try to make it mostly web-based. Doesn't seem like there's any reason it couldn't be, if you paid close attention to responsiveness (maybe you'd have to run the database and web server on the local network/host).
I'd argue that a web-based POS would suck. Most POS Users are non-technical, and so it would be hard for them to use, for example, the print option from the browser (because of the print dialog) instead a custom print option of a native app. Even having a page on the bookmarks can be hard for some users (I am saying this because I've seen it happen).
Besides, most of POS systems need to communicate with a display (the thing that shows the price) and other devices (money drawer, etc), so I can't see how you would accomplish that from a web page.
Of course, if you don't need this features and/or are doing the thing as an experiment, just ignore my post :)
Besides, most of POS systems need to communicate with a display (the thing that shows the price) and other devices (money drawer, etc), so I can't see how you would accomplish that from a web page.
Of course, if you don't need this features and/or are doing the thing as an experiment, just ignore my post :)
Is there any particular reason why it should be web-based?
I'm just guessing, but it would probably be more portable to different platforms – the only thing each OS would need is its own local server and (probably full-screen) web browser.
Also, it might be nice for a manager to be able to look up how sales are doing when they are not in the office. Of course, this could be done without making it totally web-based, but it would be harder.
It might be easier for users to customize the system, too – it is easier to change the GUI of a web app, I think (like adding more buttons to a window). The users could also perhaps use a custom stylesheet in the browser if they didn't like the look, though ideally the PoS app would allow changing the look from from within itself.
Also, it might be nice for a manager to be able to look up how sales are doing when they are not in the office. Of course, this could be done without making it totally web-based, but it would be harder.
It might be easier for users to customize the system, too – it is easier to change the GUI of a web app, I think (like adding more buttons to a window). The users could also perhaps use a custom stylesheet in the browser if they didn't like the look, though ideally the PoS app would allow changing the look from from within itself.
Recommendation: Python, commandline; then wrap a GUI around it.
Any programming language, but preferably FOSS, of course, as this will be on a Linux system.
Thanks :)