Re: [Discuss] Turbotax
On Mon, 12 Jan 2015 22:11:34 -0500, ma...@mohawksoft.com wrote: > If you are like me, your taxes can get kind of complicated, especially if > you do any consulting on the side. I have used turbotax for a very long > time, but I hate corporate sleeze. If you have a complicated tax > situation, your handy turbotax deluxe may no longer work for you. > > http://www.nytimes.com/2015/01/10/your-money/taxes/users-say-turbotax-deluxe-is-not-as-deluxe-as-previous-versions.html I posted the following review on Amazon (which is has almost 90% 1-star reviews): May the seeds of greed bear bitter fruit. Like numerous other _former_ Turbo Tax users, I find Intuit's greed here to be disturbing. The company's responses are a mix of disingenuousness (the old product lineup was confusing), belittling (only 2-4% of users are affected), greasing the squeaky wheel (we'll give you an upgrade if you call and complain loudly enough), non-answers (you can still use schedules C, D, and E -- but then it won't error check your return, and you'll have to paper file), and general irrelevance (you can call one of our customer service reps who will be happy to recommend what version you should get). Had the immediate response been "yes, we see that we messed up really badly; we will give everyone who bought a copy of Deluxe an upgrade, no questions asked, we'll sell the top of the line product for the Deluxe price, and we've learned our lesson and will do right by our customers in the future", this might have blown over. Now? No way. I have posted a link to this review page to Facebook, where I have quite a few friends and followers whom I don't want to see be shabbily treated. That will probably cost Intuit more sales, not just people who will now realize that the old mainstay Deluxe is not the right product, but also people who might not have been directly affected but whose sense of honor and propriety is outraged by such sharp practice. I can't say for certain, but if the company is correct that only 2-4% of its customers are affected, I expect that the loss of sales will greatly outweigh the incremental revenue from higher prices. I certainly hope that that is the case. And by the way, [Intuit VP] Mr. [Bob] Meighan, if you were concerned about inconsistencies in your product line, you could have chosen to upgrade the functionality of your online and mobile products to match those of the desktop rather than the other way around. And if the bottom line really was the bottom line (as you have implied with your comment about "duty to shareholders"), you could have raised the prices by 5-10% across the board with at most mild grumbling. -- Robert Krawitz *** MIT Engineers Football -- Historic 10-1 2014 NEFC Champions *** MIT VI-3 1987 - Congrats MIT Engineers 6 straight men's hoops tourney Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
[Discuss] Turbotax
If you are like me, your taxes can get kind of complicated, especially if you do any consulting on the side. I have used turbotax for a very long time, but I hate corporate sleeze. If you have a complicated tax situation, your handy turbotax deluxe may no longer work for you. http://www.nytimes.com/2015/01/10/your-money/taxes/users-say-turbotax-deluxe-is-not-as-deluxe-as-previous-versions.html ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] No-SQL Database Recommendation?
ma...@mohawksoft.com writes: > As a side note, I understand your antipathy toward to SQL, but it is > merely just anther data access grammar with individual vendor variation, > no different than using different compression libraries. There does seem to be a Python implementation of Date and Darwen's D. In this case relational is not wanted but in other cases maybe it would be of interest since SQL is apparently widely loathed here: http://www.quicksort.co.uk/DeeDoc.html Gee, what would you name a D (database language specification) implemented in the D (C++-like) programming language? Okay, maybe some inappropriate humour there, so never mind. -- Mike Small sma...@panix.com ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] No-SQL Database Recommendation?
On 01/12/2015 01:13 PM, ma...@mohawksoft.com wrote: As long as the "relational" refers to your database schema and not the underlying technology or access API, I can agree. I am feeling relieved that the no-SQL aspect of my query was pedantically correct in that I don't object to relational database software, it is the specific language "SQL" that I want to avoid. (And it looks like I can.) -kb, the Kent who finds SQL reminds him of Fortran, not that Fortran doesn't have its place, just that he doesn't want to program in either language. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] No-SQL Database Recommendation?
On 01/11/2015 09:12 PM, John Hall wrote: I'm not convinced you need a database. Writing your own simple persistence layer can be really easy and reliable with Python. Interesting suggestion, rolling my own is tempting, and when someone else suggests it...the temptation rises. But the multiuser part is a pain, I am happy to let someone else invent and implement that for lazy old me. Assuming that really is the lazy way out... I'm curious about what the intended application is, Until my project is closer to reality, I would like to avoid specifics. Certainly I am looking forward to getting things working well enough to demo, believe me. the OS distribution you are using, hardware and other loads on that hardware. So far I have been playing on Ubuntu because it is handy. (Though lately I have been losing patience with Ubuntu and preferring Debian. You know, prejudices and aesthetics again.) I'm concerned that your Mongo issues might be due to some system bottleneck that you might run into with another solution as well, anyway, try using "nice" to prioritize your processes and "ionice" to make sure background processes and cron jobs don't dominate your disk io. The fact mongodb was proudly telling me it found a half million records made me think it was spending at least some time to even know it found a half million records--where I only want a few records, and want to get those few records appropriately quickly. I looked for some tuning option to not do that work, but didn't find one. I assume you've heard about SQLAlchemy Yes, I think I have heard the name before, but that's all. On your recommendation I have looked it now: It looks nice! Quite Pythonic, I think it will let me aim my brain at other stuff again. I think my immediate todo turns into something close to: - install postgresql and sqlalchemy - create my user - fire up python to create my tables, index my time field, and a stuff in bunch of fake data (looks like the wikipedia article is a nice enough cheat sheet to make me dangerous) - see if I can figure out how to do my "gimme just a few of the many hits" limited query, and see how fast it is I suspect Postgresql will handle it well, quick Googling suggests the minimal RAM foot print is plenty small for me, and if it turns out I later *do* want any replication or relational stuff, Postgresql has those features. I agree with others that if you need a database PostgreSQL would be a fine solution and with Richard Pieri's original litmus tests on if you should consider a nosql database. SQLAlchemy looks like it will shield me from the SQL stuff I dislike. And if I must craft a few SQL statements for debugging purposes, I can do that, I can be tough and face the music, if I have to. I'm just a whiny brat who is spoiled by how nice Python is. (Python really is wonderful. Trying out some new library is easy and I can start writing code quickly. By the time I have really understood what I precisely want to do...I mostly have a working program. Maybe not final, but working. Certainly Python has flaws, such as having an adhoc language definition and being a big, monolithic, single-threaded interpreter, but it is nice anyway.) Thank you for your thorough suggestions, -kb ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] No-SQL Database Recommendation?
On 2015-01-11 17:58, Kent Borg wrote: I would like something that has a nice Python API. But if I can't I can't. If the no-SQL part has to be discarded, so be it. I don't need relational features, but I don't mind if my database supports them. There is nothing in my data that needs a free-format key/value features. Maybe there is a nice Python interface to PostgreSQL that hides SQL bits, but I doubt it. Have you considered SQLAlchemy ? It has a Core layer that is essentially a Python interface to SQL and an ORM layer that allows you to use objects to implicitly manipulate the database. In addition, you can swap out backends, so you're not necessarily stuck with an initial DB choice. Chris ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] No-SQL Database Recommendation?
> On 1/11/2015 4:26 PM, ma...@mohawksoft.com wrote: >> This is absolutely wrong. A simple key/value table in SQL is perfectly >> fine. Why would anyone assert otherwise? The fact that you *can* use it >> as >> a relation is beside the point. > > As an aside... > > I don't mean key/value data. I mean N-dimensional data where N > 2. > Medical records are (can be) a relatively simple example of > 3-dimensional data: they cover patient information over time. Sparse > array databases were developed specifically because these kinds of data > don't fit into tables. > > My assertion stands: trying to shoe-horn non-relational data into a > relational database is foolish. As long as the "relational" refers to your database schema and not the underlying technology or access API, I can agree. > > -- > Rich P. > ___ > Discuss mailing list > Discuss@blu.org > http://lists.blu.org/mailman/listinfo/discuss > ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] No-SQL Database Recommendation?
On 1/11/2015 4:26 PM, ma...@mohawksoft.com wrote: This is absolutely wrong. A simple key/value table in SQL is perfectly fine. Why would anyone assert otherwise? The fact that you *can* use it as a relation is beside the point. As an aside... I don't mean key/value data. I mean N-dimensional data where N > 2. Medical records are (can be) a relatively simple example of 3-dimensional data: they cover patient information over time. Sparse array databases were developed specifically because these kinds of data don't fit into tables. My assertion stands: trying to shoe-horn non-relational data into a relational database is foolish. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
