Editing Twitter Analysis DB

Jump to navigation Jump to search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Latest revision Your text
Line 1: Line 1:
 
= Goal =
 
= Goal =
This document could use improvement, but the software largely works ( see Status below ) and I am probably done unless there is expressed interest in knowing more, or I add major new features. Look at history tab to see what is going on in the document. If you would rather look at at the application than read about it see [[Twitter Analysis DB GUI]] which you should check out at some point in any case.
+
This document is new, the software is alpha but "works" Look at history tab to see what is going on. If you would rather look at it than read about it see [[Twitter Analysis DB GUI]]
  
 
Twitter Analysis DB is a Python open source, program and an accompanying database, running in a Graphical User Interface tool ( and/or database creation tool ) for the analysis of a body of tweets.  Currently the program is in early alpha and its design goals are evolving at least as fast as the code is being written.
 
Twitter Analysis DB is a Python open source, program and an accompanying database, running in a Graphical User Interface tool ( and/or database creation tool ) for the analysis of a body of tweets.  Currently the program is in early alpha and its design goals are evolving at least as fast as the code is being written.
Line 32: Line 32:
 
* Overall structure seems sound and extensible.
 
* Overall structure seems sound and extensible.
 
* Should be relatively easy to add additional queries, joins, columns, select criteria, without massive coding effort.
 
* Should be relatively easy to add additional queries, joins, columns, select criteria, without massive coding effort.
* But.... it is full of opportunities for enhancement. Right now my interests have shifted so I may not do much further workPossibilits for improvement:
+
* But.... it is full of rough edges. Almost nothing has been polished upCited for improvement:
** Clean up tweet in the database build stage.  Pretty good not but still some odd "words" get through.
+
** Clean up tweet in the database build stage.  Much "junk" like odd Unicode characters need to be managed.
 
** User interface is evolving but still not as user friendly as I would like.
 
** User interface is evolving but still not as user friendly as I would like.
** Selects == (also know as Reports or Queries... ) are more demos of what is possible than what is truly useful and informative, several are experiments in the technology of the application.
+
** Report == Selects are more demos of what is possible than what is truly useful and informative.
** Sqllite still doing ok at 4 years of trump tweets and 300k of words.  
+
** Biggest db so far has 300K words and only Trump tweets for this year.  Need to do a bigger db load, see how sqlite holds up.
** No database optimizations yet.... I run on ram drive for speed. DB is about 40 MBytes with 4 years of trump tweets
+
** No database optimizations yet.... I run on ram drive for speed
** Report formatting is basic, but workable.  Nicest overall format for human readability is probably "html", best to pass to other applications is probably "csv", most responsive in time is "msg"  -- sent to message area, often sub second response.
+
** DB is about 20 MBytes so not so bad
 +
** Report formatting is basic, but workable.  Nicest overall format for human readability is probably "html", best to pass to other applications is probably "csv", most responsive in time is "msg"  -- sent to message area ( implementation delayed due to unicode problems )
 
** Not sure what area of work is most useful, have been driven lately by programming challenges need to focus for a bit on improving usefulness.
 
** Not sure what area of work is most useful, have been driven lately by programming challenges need to focus for a bit on improving usefulness.
** Still printing some unnecessary junk used in debugging, remove most... if output is needed sent to py_log, but whole logging parts of the application could use a careful review ( not happening soon ).
+
** Still printing lots of junk used in debugging, remove most... if output is needed send to py_log
  
 
'''What technical knowledge should users have ( and How ):'''
 
'''What technical knowledge should users have ( and How ):'''

Please note that all contributions to OpenCircuits may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see OpenCircuits:Copyrights for details). Do not submit copyrighted work without permission!

Cancel Editing help (opens in new window)