search

martinatime / SuperDeDuper_archived

A program for cataloging, updating, and reducing duplicates of MP3 files
1 stars 0 forks source link

Determine the development environment #2

Closed martinatime closed 11 years ago

martinatime commented 11 years ago

Determine: Source control - I'm assuming Git Programming Language - Java, Ruby, Python, whatever it just needs to be decided Documentation - Wiki will be used for some documentation IDE - Eclipse maybe...depends on language Other Tools Testing - I would like to try Test Driven Development Data Store - NoSQL? SQLite? Other?

When this is formalized it will be placed in the wiki.

evnjones commented 11 years ago

Some initial thoughts:

Data Store Another possibility to add to the list of options (NoSQL and SQLite) is Lucene.

Programming Language This choice goes hand-in-hand with deciding on what technologies will be used in the actual product to implement the desired functionality. The biggest constraint will be availability of APIs and bindings in a given language based on the chosen technologies (data store, gui vs. cmd line, gui toolkit, etc.). But, consideration should also be given to competency (and/or desire to gain competency) in a given language.

IDE Eclipse is probably the best bet, as there are plugins for many different languages, along with integrations with issue tracking and version control. The big draw away from Eclipse would be if we choose a MS-specific language, then Visual Studio may be a better choice.

Testing I haven't used Test Driven Development, but I'd like to learn. I'll do some reading to get a better idea of what it consists of.

martinatime commented 11 years ago

I'm up for learning anything. I'll do some research over the next few days and put up a few lists of potentials for each category.

martinatime commented 11 years ago

After reading the article http://en.wikipedia.org/wiki/NoSQL I feel that we can get the scalability we need from a NoSQL db. I'm not certain which db to use but I think either the Document Store or Key-Value type makes the most sense. I've heard of many of these but but I have not used any of them. I'm not certain what "allowing for multiple query paths" refers to. I haven't looked into lite-weight SQL based databases yet but that'll be my next research.

evnjones commented 11 years ago

What I meant with "allowing multiple query paths" was that we need to retain the ability to query on different data elements of the records/documents in the data store. The wikipedia article you referenced does indicate that the various NoSQL db implementations support some type of field-based querying, so I think we are covered there if NoSQL is the decided direction.

The article calls out the benefits of NoSQL dbs to scaling across multiple machines/shards/etc, but I didn't see any information on if they are can be embedded within an application. This is a critical property to look for if/when we start looking into which NoSQL db is appropriate for our use. I don't think we want to have a pre-req for our application that an enterprise-class datastore application be installed.

This article http://en.wikipedia.org/wiki/Embedded_database has some information and examples of embedded databases. Some of these are pretty mature (e.g., SQLite, Derby), so pretty stable and we wouldn't be asking them to do anything out of the ordinary.

martinatime commented 11 years ago

I see your point. I think I'm leaning towards SQLite based on the minimal research that I have done.

evnjones commented 11 years ago

SQLite seems the most flexible, in terms of what programming languages are supported for either direct API access or DB driver access (http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers). That being said, if we decide to use Java, then we might better be served by using Derby instead of SQLite.

Alternatively, I'm still intrigued with the idea of using Lucene as the data store. There are fewer programming languages supported (http://wiki.apache.org/lucene-java/LuceneImplementations), but if we won't be needing a relational datastore, Lucene seems, to me, to be a viable option.

evnjones commented 11 years ago

Ok, after reading through the requirements, maybe using both SQLite/Derby and Lucene would be a good approach. SQLite/Derby for tracking user preferences and historical records in the catalog and leveraging Lucene for the master catalog and for searching. Thoughts?

martinatime commented 11 years ago

Ok, I'm in agreement. Let's just go with Derby and Lucene for now. We can reevaluate if needed.

As far as programming languages. I think we should go with java. Although for some future project I think I want to spread my wings a bit I don't want to throw in too much new stuff. For instance if we wanted to the iTunes integration then Apple has iTunes SDKs but I don't think they have Java included so JNI would have to be used to map the COM objects (and associated OS X libraries) in.

evnjones commented 11 years ago

Can we finalize this issue?

If you're good with these decisions, I'll move them to the wiki for documentation and close this issue. Also, I'm not familiar with Test Driven Development. Can you recommend any resources I can read to get up to speed on it?

martinatime commented 11 years ago

I have Pragmatic Unit Testing In Java with JUnit http://amzn.com/0974514012 I went through it a while ago but I haven't used much of it in practice http://en.wikipedia.org/wiki/Test-driven_development

martinatime commented 11 years ago

I also have Pragmatic Version Control Using Git and Pragmatic Project Automation.