As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been trying to choose between the three accounting software. However, I can't decide which one should I use. In terms of user interface, I would go for PeachTree and QuickBooks. MYOB seems too old IMHO. In terms of using for software development, I would go for QuickBooks because I think there are many developers using it and the SDK can be easily downloaded. Also, do these software support currencies aside from dollar? What SDK is easy to use for .NET development? TIA.
QuickBooks is very mature and much, much more popular than either other system. It's also much easier to find an accountant familiar with QuickBooks than it is to find an accountant familiar with either of the two others.
As far as development goes, QuickBooks has a reasonably strong developer community behind it, and integration/the SDK is pretty flexible. There is an official QuickBooks SDK that's pretty easy to use and is downloadable from Intuit's site. The forums are also a good resource:
https://idnforums.intuit.com/
To answer the question about SDK's (selecting an accounting package for everyday use is beyond the scope of this site), I've used both Quickbooks and Peachtree; I don't know anything about MYOB. Here we go.
Quickbooks:
A lot of stuff is hidden by the COM interfaces, so you end up having to do tricky type casts that you have to look up in the documentation. And since you'll be doing this every time you unwind a results list, it happens quite frequently.
It's confusing at first because the framework is actually quite powerful in terms of result filtering. This, coupled with the previous point, makes getting started a little difficult.
The documentation is not the greatest, but is more or less complete. Some of the examples are convoluted and unhelpful, but most of the time you can get what you need from them.
Actually connecting to Quickbooks is quite slow. The API lets you aggregate requests (i.e., on one call, you can query customers and items at the same time) which helps out a little bit.
There are a lot of little quirks in the API
The API is interface-centric
There are some features in Quickbooks that are implemented much differently than in other accounting packages. These things show through in the API, which in turn makes it more difficult to write code. Sometimes it makes sense, sometimes it doesn't.
Peachtree:
Connecting and querying is very fast, but involved queries (such as invoices) are very very slow, even when only a single field is returned.
Results come back in XML, so it's not as automatic as having things come back in .NET objects, but at least it's easy to process. Some of the XML structures are a bit bonkers (attributes attached to the wrong element), but processing that isn't a huge deal.
The documentation (a single Word document) is pretty bad, and the developer community is essentially under lock and key (you have to be a partner with Sage, i.e., $$$, to get access to their online forums). Googling "Peachtree SDK"-anything returns zero useful results.
The API is enum-centric, and the enums aren't documented very well. API classes and interfaces are named poorly (no I-prefixed interfaces) such that name collisions are likely... so you'll have to alias the API namespace in most cases. The enum names themselves are unbelievably long. Sometimes it takes 2 lines to specify a single enum value, which is unbelievably messy and annoying (example, without namespace alias: PeachwIEObjCustomerListFilter.peachwIEObjCustomerListFilter_CustomerName).
Result filtering isn't as powerful as Quickbooks, and in fact I'm struggling to get it to work at all (with an example lifted directly from the docs) is essentially useless.
From what I've read, API support is less than stellar (it seems like Sage aren't really developing it any more, and they may possibly be phasing out Peachtree altogether)
The implementation is less complete than Quickbooks
Both APIs have their strengths and weaknesses... I couldn't really give any kind of recommendation for either without knowing what type of application you're targeting, and how extensive your needs are.
I use MYOB as the main accounting package for a law firm employing 10 people. The program integrates with another package we have to use for statutory Trust accounting. Of the two programs, MYOB is noticeably superior. It is easier to use and is extremely robust and reliable. I have not used Peachtree or Quickbooks but rate MYOB as 9/10 and would be reluctant to change.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am developing a site using Ruby on Rails. I would like to develop the REST API (JSON) separately to maximize performance, the Rails stack just takes away too much.
Are there any performance benchmarks out there? What do you think would yield the best performance? I am currently thinking about the following, because that's what I have experience with. Is there anything else I should consider? It should be lightweight.
node.js
Scala Spray (http://spray.io/)
Ruby Sinatra
Thanks!
Summary: Maximize your performance as a developer. Use stack you know best. First make it work, then make it fast.
Are there any performance benchmarks out there?
There are all kinds of benchmarks out there. Let's say, node.js can handle 100k HPS (helloworlds per second) and Sinatra can only do 80k. What does it tell you? Nothing.
Also, sometimes higher performance comes at a great cost. Take ruby C extensions, for example. Sure, C runs faster than Ruby, but it prevents other threads from running on other cores (because of GIL).
So, don't choose tech only by benchmark figures from the internet. There are so many factors to consider besides raw HPS number.
LINK: If you think Rails is too heavy, you should try rails-api. It's basically a stripped down version of Rails (you don't need things like cookie authentication or MSIE rendering helpers in an api server).
Personal story
I run an API server that handles some load. First version was written with Rails. Then I thought "Hey, Rails Is Bloated (c), let's rewrite everything with Sinatra". And then I had waves of frustration coming one after another. It turned out that Rails does a lot of small but helpful things which I didn't appreciate. I gave up, rewrote it with Rails again (applying lessons learned) and lived happily ever since.
This falls into the 'should I rewrite my apache/php site in C with a customized webserver because it's slow' bucket.
I vote for picking your favorite stack to work in and utilize good caching and using whatever opcode optimization you've available if your code isn't compiled. Then make sure you've got adequate server resources and load balance horizontally if needed to handle the traffic.
I've yet to see many API's whose primary reason for poor performance is the choice of technology stack unless they're handling facebook/twitter size traffic or doing computationally intensive work.
You'll see in just about any stack you choose if properly utilized more latency occur in:
Transport of unnecessarily large amounts of data to the client
Performance hits due to poor SQL or other data source fetching slowness
I'd also highly recommend if you're already using a RoR stack to stick with it. Trying to optimize and code in different stacks will generally result in weaker code in both--keep your dev's brains focused in one pool of futz at a time.
It really depends on your usecases and team experience/preferences - BUT, if you are truly open-ended about whatever stack, our personal experience was:
Scala + Scalatra + Jetty was simple and very fast.
Node + Express was surprisingly close in speed - but with the benefit (in our case) of flexible Javascript code.
Ruby was much less performant than either, but had cool code.
Scala was a winner because our shop has lots of experience in the JVM.
Hoever, we hope to leverage node more in the future do to the simplicity.
I'm sure experienced Ruby guys could do improve and tune things, but it wasn't worth the learning-curve for us and a non-starter.
Check out spray -- I like it because it is lightweight and well-designed (modular, asynchronous, sane API). For web service stuff most web frameworks just come with too much baggage.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm building a new game and I need to build a web app to help manage content generation. The app would consist of a couple simple forms that would tie into a MySQL db.
I've been really interested in learning Lua for a long time due to it's large popularity in the video game industry and was wondering how well it works as a server side language. I could easily write the web app in PHP but I'd rather use this opportunity to learn Lua if it makes sense.
What do you all think?
Cheers,
Sure it can be done. Good idea if you just want to learn Lua. You should start here: http://www.keplerproject.org/
Of course, if your app would consist of a couple simple forms, you can use all what you want. But if it is more complex (will become more complex in future) it will be better to use some industry standard languages like Python or Ruby (or, at least PHP), there are a lot of good frameworks writen in them that very simplify your work (I don't know about any complete lua web frameworks) .
You should remember, that in future other people will have to maintain your code and there are very few web-developers who know Lua.
Probably, there will be problems with documentation and basic libraries too.
While LUA is a nice language for embedded development but i would extremely vote against LUA for web development.
The reason is that in Games you simply don't have an external API. All is done with your own objects only some calls into your game engine.
But the web world is so full of stuff you need, like SMTP, POP3, IMAP, SSL, Amazon APIs, Google APIs, RSS Apis, Imaging etc. and while the checklist for LUA may have a check mark behind all this words - it doesn't mean anything. Most of the stuff i have seen is just a "me too| implementation but not industrial strength. They are projects by hobbyists and are published on a "Its good enough for me" basis which is total unacceptable if you ever go mission critical.
There is a reason why it takes years and a huge community to get this up. Lua has an extremely small community of web developers.
So if this is a professional project where you put your money i can only say hands off. On the other side if you have enough money i still have some snake oil here for sale, please contact me.
I have been using lua for years as a web language. Initially using the Xavante project and more recently apache2.
Dont listen to any neigh sayers, its a great language for web developement and we use it to write business software, and not just for form processing, for graphical applications too.
Also it offers us seamless integration to any other lua or system functions we might need to call.
Good Luck!
Have a look at Nanoki which is built on a pretty minimal set of libraries (lfs, luasocket, lzlib, slncrypto)
and Sputnik which is built on Xavante or CGI
Lua is a good language but it is best suited to embedding within an existing project in order to quickly extend the capabilities of that project. In particular, the interesting aspect comes with how you bind it to the host application. This is definitely the case when programming for games where it is an embedded language rather than the language the whole app tends to be written in. So using a web app to learn about Lua with a view to making games is probably not a very good approach, especially since the syntax is very simple and would be picked up quite quickly anyway.
I think that specific variants of lua can be used successfully for web applications and I have done that in the past using the maintained weblibrary. It can depend on if the lower level software on the computer is itself written in lua because of its high speed and this may cause a clash of lua versions. Regarding a serverside possibility the server would need a compatible version of the script developing facility for the hardware and a suitable bytecode or VM instructions and custom VM runtime implementation for running the application.
I've been developing a pure Lua Web Server, you could always check it out and see if it suits your needs
Lua4Web https://github.com/schme16/Lua4Web
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have been using Grails for the past few months and I really like it, specially GORM. However, I am getting interested into Scala's Lift. Therefore, I would like to know your opinion about which kind of web apps are better suited for which of those two frameworks or it is just a matter of taste, which framework to use?
Finally, which of those frameworks do you think will be more used in the future?
I have the feeling that Grails is far from reaching a critical mass and it still remains very obscure (in the past few months I had the opportunity to work with middle size companies and IT startups working mostly with the JVM stack and only one person knew and used Grails) and I am not even sure if it can become the "RoR" of the Java world (Indeed reports a drop of growth in the last few months even if other frameworks have a positive growing rate). And I love Groovy, it is really easy to learn but I have noticed how slow it can be for some tasks.
On the other hand, Scala seems to be more popular (Tiobe Index) and the fact that Twitter is using it now gave it even more presence in the blogosphere with lots of lovers and haters making buzz. It is famous for being fast and scalable. However, the language seems somewhat hard to understand and learn for lots of developers (so maybe it will never gain mainstream status). Lift is little known and I have read some reports that it is better suited for small apps (less than 20 domain classes).
By seeing the number of books published Groovy-Grails dominate right now, but many publishers have Scala books on the works, so I think this advantage will not last long.
Finally, we have the problem that both languages and frameworks still have poor IDE support (it is getting better by the day but far away from what Java shops expect to be productive).
I do not want to start a flame wars, but I would be very interested to hear other users' opinions.
The accepted answer here takes a really ignorant view on Groovy - it is a modern, dynamic language (dynamic vs. static is a huge debate in and of itself, and not particularly relevant here). This is by design, and therefore not a disadvantage, just a difference. It has a lot of modern language features that Java does not have such as closures, native regexp, polymorphic iteration, some optional static typing (matter of debate, but also look at groovy++), native syntax for lists and maps, etc.- you can see a comparison here http://groovy.codehaus.org/Differences+from+Java
To address the actual question of Grails vs. Lift, I'd say Grails hands-down. It has the SpringSource behind it, and just look at the plugins page http://www.grails.org/plugin/category/all - I can't even find what plugins or equivalent are available for Lift. Grails is also on top of the latest cloud-friendly technologies, with features like native RabbitMQ messaging support, and turnkey GORM support for MongoDB and Redis.
Grails is a nice idea(but only "stolen" from rails) but the fact that the groovy guys are not interested in getting proper Eclipse support is hindering it's success a lot. I've even seen Eclipse questions not being answered at all on the grails lists.
I agree with Tim that Netbeans 6.7 finally delivers the first half way usable Open Source IDE support for groovy/grails - and eventually, SpringIDE will also feature better groovy/grails support.
The reason many Java folks love Java is the static typing, which enables tools to help you a lot with many things. This is lost with a language as groovy.
Yes, I could write every really important piece of Code in Java and still use Grails - but then, why should I, just to save a bunch of lines of glue code, do that instead of learning to use a Java framework highly effectively?
To come to an end: I did not yet look at scala, but built some simple apps with grails - and I tend to go back to java, even reimplementing every app that needs further development in a plain Java framework - I think wicket and Seam.
I'll also look at Scala/Lift, I heard many good things about it!
BTW: I'd compare communities and look at mailing lists - how many peope are there, do they get good answers on their important questions?
Grails seems to have a non-answered rate from nearly 50%, which I feel is bad.
Grails support in netbeans 6.7 is really good, as well as the idea intellij support in Maia.
Eclipse is still pretty sucky.
I looked at lift, but was concerned about the resources available now; this will change in the future, but my projects can't wait.
I would like to specifically answer the question "for which kind of applications". The main difference between the philosophies of Grails and Lift seems to be that Grails enforces MVC whereas Lift seems to be more liberal i.e. it doesn't enforce MVC but provides enough avenues to use MVC if you want to.
Also Lift seems to be excellent for 'Single-Page Applications', especially if you need to implement a server-push functionality using technology like Comet (which obviously doesn't imply it's not good for other types of applications). On the other hand, Grails seems to be better for the 'Enterprisy' applications, especially if you are already familiar with Spring and Hibernate but want your app to be much more concise (using Convention over Configuration) than what a non-Grails app would be using these technologies.
References:
Simply Lift, chapter 13
Single-Page Application
Disclaimer:
I have just started exploring Lift and built some simple apps using Grails.
With all the performance improvements and advancements of Grails2.0, with great support provided by IntelliJ 11 for the framework, an ability to plugin pretty much any advanced web technology into your grails app., and yes - VMware weight behind it - I really don't see how Lift could be an advantage or a good choice. Just think of using two different languages in the same application, need for double expertise in the team, etc.
The original question has been posted like 2+ years ago and I think time showed on which side is the choice of the dev community ;)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm interested in building a site that has several interactive features for the users, yet want the site to be relatively light and avoid using Java or Flash. The site will start small but will hopefully be scalable. I realize developers tend to prefer a specific language and/or CMS and am wondering if you think a particular language would be best for creating a site with these features:
Short user profiles, photo upload, automatically generated thumbnails, a simple rating system, photo galleries, a blog section, ability to serve ads, user verification, polls, forms to enter contests, a taggable, searchable how-to library, a video library (using videos hosted on other sites)
I'd recommend you checkout Drupal CMS. Drupal covers almost all of your needs by means of drupal modules and/or drupal core itself.
Using drupal is easy, you don't have to be a programmer. Eventually you can hire a drupal programmer to take care of certain things that may not come with drupal or may not have any modules available. The other plus of a drupal programmer is that they are already familiar with the technology and can help you much more faster.
I would go for a python or ruby web application framework, say Django or ruby on rails, if this is going to be a single developer project it would probably make sense to leave it open on what framework to use - familiarize yourself with the frameworks and interview a wide variety of candidates.
Hire the best applicant and go for the framework of his/her choice - if he's any good, he can definitely tell why his choice is better than the other ones, not just claim that "it is" (or worse, it is the only one I'm familiar with)
wikipedia list of the frameworks
The best setup would be COBOL, with a UNIVAC on the back-end for storage and a vintage Enigma machine in between.
Or, alternatively, find the person you want to hire and let them decide. From the tone of your question, it would appear that you don't trust your technical abilities. What makes you think that you're going to get good advice from a bunch of random people on the internet?
Find a good consultant that has done work similar to what you're trying to do and let them decide on the tools. In the long run that will be the cheapest because paying someone to learn a new set of tools will be much more expensive than any other costs that might be associated wit ha particular set of software.
Any language will do the trick (although Prolog could be too tricky). Use what you know best unless you want a tradeoff for self-education in which case use the language you want to learn next.
I would recommend using Django framework which is based on Python language.
It's a tradeoff. "First with the worst" is a time-honored recipe for success. That would be PHP, huge first-place presence, cheap hosting, lots of existing frameworks, lots and lots of bad code. More sophisticated, in second place, would be Python. Yet more sophisticated, in third place, is Ruby. I'm not exactly sure where perl ranks in web development.
Note that you will tend to attract a slightly different kind of partner/developer/employee with each choice.
If it were me, I would go with Ruby plus a framework, perhaps RoR, unless one of the PHP CMS packages was really close to what I needed.
So much for opinions, here is a language and platform agnostic thing to consider: with the recent availability of cheap VPS hosting, you really can have any kind of site you want, yet you don't need to run your own machine room. It makes Java and the other JVM languages more attractive, I think.
If you want cost effective solutions then I will suggest you to go with LAMP. You will get almost all your required features in free open source scripts. Again the development of LAMP is comparatively cheap then ASP.Net.
By LAMP I mean Linux, Apache, MySQL, PHP.
The hosting expenses of LAMP are also comparatively cheap.
There is no absolute answer; You will have as many answers than users.
Do not re-invent the wheel!
First of all you will need to define your wishes - almost done.
Then choose a product regarding to the price.
Finally, find a specific employee.
For your needs, you can look at:
joomla
sharepoint
eroom
openText
blog platform
framasoft, chapter CMS
Some thoughts:
I highly recommend against Drupal. My experience is that it is entirely too bloated to be considered less than obese (let alone light).
I've heard NOTHING good about wordpress.
Joomla has a good reputation, but it also has the reputation of having a higher learning curve (I've never spent real time with it). If you're hiring someone, however, this should be irrelevant.
Personally, my favorite systems in PHP are from EllisLab Inc. -- Expression Engine and Codeigniter. Both of these are very well written and generally lay a groundwork for reliable and maintainable code.
Ruby generally has the reputation of being simple enough to build in.
I would use caution with Python, because it is in the midst of a transition between incompatible versions and that could be hell.
I'd go for ASP.NET.. it's trivial to build the things you mention with WebForms, although I would go for MVC in a larger project.. just my 2 cents..
as far as hosting expences goes Windows and Linux is nowadays pretty much the same...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is there anyone working solo and using fogbugz out there? I'm interested in personal experience/overhead versus paper.
I am involved in several projects and get pretty hammered with lots of details to keep track of... Any experience welcome.
(Yes I know Mr. Joel is on the stackoverflow team... I still want good answers :)
I use it, especially since the hosted Version of FugBugz is free for up to 2 people. I found it a lot nicer than paper as I'm working on multiple projects, and my paper tends to get rather messy once you start making annotations or if you want to re-organize and shuffle tasks around, mark them as complete only to see that they are not complete after all...
Plus, the Visual Studio integration is really neat, something paper just cannot compete with. Also, if you lay the project to rest for 6 months and come back, all your tasks and notes are still there, whereas with paper you may need to search all the old documents and notes again, if you did not discard it.
But that is just the point of view from someone who is not really good at staying organized :-) If you are a really tidy and organized person, paper may work better for you than it does for me.
Bonus suggestion: Run Fogbugz on a second PC (or a small Laptop like the eeePC) so that you always have it at your fingertips. The main problem with Task tracking programs - be it FogBugz, Outlook, Excel or just notepad - is that they take up screen space, and my two monitors are usually full with Visual Studio, e-Mail, Web Browsers, some Notepads etc.
Go to http://www.fogbugz.com/ then at the bottom under "Try It", sign up.
under Settings => Your FogBugz Hosted Account, it should either already say "Payment Information: Using Student and Startup Edition." or there should be some option/link to turn on the Student and Startup Edition.
And yes, it's not only for Students and Startups, I asked their support :-)
Disclaimer: I'm not affiliated with FogCreek and Joel did not just deposit money in my account.
When I was working for myself doing my consulting business I signed up for a hosted account and honestly I couldn't have done without it.
What I liked most about it was it took 30 seconds to sign up for an account and I was then able to integrate source control using sourcegear vault (which is an excellent source control product and free for single developers) set up projects, clients, releases and versions and monitor my progress constantly.
One thing that totally blew me away was that I ended up completely abandoning outlook for all work related correspondence. I could manage all my client interactions from within fogbugz and it all just worked amazingly well.
In terms of overhead, one of the nice things you could do was turn anything into a case. Anything that came up in your mind while you were coding, you simply created a new email, sent it to fogbugz and it was instantly added as an item for review later.
I would strongly recommend you get yourself one of the hosted accounts and give it a whirl
In addition to the benefits already mentioned, another nice feature of using FogBugz is BugzScout, which you can use to report errors from your app and log them into FogBugz automatically. If you're a one person team, chances are there are some bugs in your code you've never seen during your own testing, so it's nice to have those bugs found "in the wild" automatically reported and logged for you.
I use it as well and quite frankly wouldn't want to work without it.
I've always had some kind of issue tracker available for the projects I work on and thus am quite used to updating it. With FB6 the process is now even better.
Since FB also integrates with Subversion, the source control tool I use for my projects, the process is really good and I have two-way links between the two systems now. I can click on a case number in the Subversion logs and go to the case in FB, or see the revisions bound to a case inside FB.
I think it's great that Joel et al. let people use FogBugs hosted for free on their own. It's a great business strategy, because the users become fans (it is great software after all), and then they recommend it to their businesses or customers.
Yea FogBugz is great for process-light, quick and easy task management. It seems especially well suited for soloing, where you don't need or want a lot of complexity in that area.
By the way, if you want to keep track of what you're doing at the computer all day, check out TimeSprite, which integrates with FogBugz. It's a Windows app that logs your active window and then categorizes your activity based on the window title / activity type mappings you define as you go. (You can also just tell it what you're working on.) And if you're a FogBugz user, you can associate your work with a FogBugz case, and it will upload your time intervals for that case. This makes accurate recording of elapsed time pretty painless and about as accurate as you can get, which in turn improves FogBugz predictive powers in its evidence-based scheduling. Also, when soloing, I find that such specific logging of my time keeps me on task, in the way a meandering manager otherwise might. (I'm not affiliated with TimeSprite in any way.)