I figure it's about time to give some love to our Google Android team, Android Connect! We've kinda kept it under the radar for a long time, but since we've already submitted our project to google for Phase 1 of their Android coding competition, I figure it's ok to talk about it now.
Our idea was to use the GPS functionality built into Android to allow phones to sense and track proximity to each other. The analogy we used in development was an infection spreading through a population. Not the most user friendly analogy, so the one we submitted under was a smile passed from person to person =). We have a webservice which accepts updates from any device running our Android Connect application, which will then track location, and infection. One of the portions that I'm working on at the moment is building an emulator to simulate a bunch of Android Connect devices roaming around downtown Honolulu. That way when a new user joins up and gives their GPS updates, if they're in downtown Honolulu, they can see their infection spread across the simulated devices in real time.
If you want to check out our Android Connect project, you please visit this website: Android Connect
Showing posts with label java. Show all posts
Showing posts with label java. Show all posts
Wednesday, April 23, 2008
Monday, March 10, 2008
Learning Struts
I've decided that I need to broaden my skillset, so I've decided to try and learn struts. I've always preferred back-end applications development, so web applications have never held an interest to me, but seeing trends in programming has led me to suck it up and try it out.
The different frameworks that I've looked at were Ruby on Rails, PHP, and JSP. I decided on JSP/struts, since it seems to have built some momentum among my peers from UHM (I read your blogs once in awhile, even if ya'll don't remember me), and I figure if it's good enough for them, I should at least give it a shot.
So far, this is what I've accomplished:
* Installed jre and jdk se on my ubuntu server dev box
* Installed ant and tomcat
* Got a sample webapp from tomcat.apache.org running (Hello World!)
My next steps are to write my own simple webapps as a stepping stone to my overall goal, which is still a secret!
The last time I wrote a webapp was waaaay back in the .NET 1.0 days. Web technology has progressed since then, I have a lot of catching up to do.
The different frameworks that I've looked at were Ruby on Rails, PHP, and JSP. I decided on JSP/struts, since it seems to have built some momentum among my peers from UHM (I read your blogs once in awhile, even if ya'll don't remember me), and I figure if it's good enough for them, I should at least give it a shot.
So far, this is what I've accomplished:
* Installed jre and jdk se on my ubuntu server dev box
* Installed ant and tomcat
* Got a sample webapp from tomcat.apache.org running (Hello World!)
My next steps are to write my own simple webapps as a stepping stone to my overall goal, which is still a secret!
The last time I wrote a webapp was waaaay back in the .NET 1.0 days. Web technology has progressed since then, I have a lot of catching up to do.
Wednesday, February 27, 2008
Comparisons between GT.M and other software ecosystems
Since the beginning of modern computer programming (circa 1980 or so), people involved in EHR's have been trying to compare Mumps to say, C/C++, or Java, or VB. Then they try to compare Mumps to common database engines, such as SQL Server, MySQL, and Oracle. Those comparisons are generally not equitable all around, as Mumps is a combination of static file storage, programming language, runtime environment, and related utilities.
As a static file storage system, Mumps alone is inequitable to SQL Server, or other DBMS's, since Mumps only stores data in B-trees. Note that in the extreme back end of SQL Server, data is also stored in B-trees, but that level is never displayed to the developer. Instead, you interact with your B-tree data by using SQL the language. VistA solves this by using Fileman, which in itself is a combination DBMS, Display API, Database API, and various programmer level utilities. So rather, a better comparison would be the disk IO speed of Java vs Mumps globals, or the query speed of SQL Server vs Fileman. As a side note, Fidelity just released a beta version of PIP, which is their own relational engine, available on sourceforge. I'm really excited to try it out!
Mumps is also not directly equatable to Java, or C. Since Mumps is also a runtime environment and set of database utilities in addition to a programming language, it's better to compare Mumps to Java and JVM, or C# and .NET, or C# and WINE.
We were running some numbers at work on a virtual machine running Ubuntu 7.1, and in a nutshell, GT.M is slower than Java and C for number crunching, but GT.M has a higher level of inherent number accuracy. The Java and C implementations were having number overflows when they used a datatype that was too small to handle the large integers we were computing. Note that this did not throw a runtime error, and the results looked real enough until they were compared to a sample set. GT.M did not have this problem, and got the correct answers from the beginning.
When compared to disk IO, I have not had a chance to compare mumps global speed vs Java or C disk IO, but in GT.M I can update 4,000,000 subnodes in 17 seconds. That is blazingly fast, but again, I have nothing to compare it against.
When compared as a database, SQL Server far outperforms Fileman. The general rule of thumb is that SQL Server is faster than Fileman by a magnitude of 4 to 1. I know that many people always say how "SQL Server and Oracle are slower than Fileman", but that is simply not true. My coworkers and I have used the exact same server with the same problem set, implemented in both Fileman and SQL Server, and run the same query to receive the same dataset. SQL Server outperforms Fileman, bar none.
In Fileman's defense, it is more than just a DBMS, it handles user IO, and has it's own programming API (date/time utilities, etc.).
Our next step will be to have a complete problem which requires a large database query, and number crunching as a cohesive unit. Perhaps then the Mumps model of tight integration will see an advantage as you can directly manipulate globals and Fileman from your code, whereas C or Java has to interact with SQL Server through ADO or ODBC.
I know I haven't posted numbers yet, but we have more testing that we'd like to do. I don't want to have anything indexed by google until I have a complete set of numbers to post at once in a coherent manner.
As a static file storage system, Mumps alone is inequitable to SQL Server, or other DBMS's, since Mumps only stores data in B-trees. Note that in the extreme back end of SQL Server, data is also stored in B-trees, but that level is never displayed to the developer. Instead, you interact with your B-tree data by using SQL the language. VistA solves this by using Fileman, which in itself is a combination DBMS, Display API, Database API, and various programmer level utilities. So rather, a better comparison would be the disk IO speed of Java vs Mumps globals, or the query speed of SQL Server vs Fileman. As a side note, Fidelity just released a beta version of PIP, which is their own relational engine, available on sourceforge. I'm really excited to try it out!
Mumps is also not directly equatable to Java, or C. Since Mumps is also a runtime environment and set of database utilities in addition to a programming language, it's better to compare Mumps to Java and JVM, or C# and .NET, or C# and WINE.
We were running some numbers at work on a virtual machine running Ubuntu 7.1, and in a nutshell, GT.M is slower than Java and C for number crunching, but GT.M has a higher level of inherent number accuracy. The Java and C implementations were having number overflows when they used a datatype that was too small to handle the large integers we were computing. Note that this did not throw a runtime error, and the results looked real enough until they were compared to a sample set. GT.M did not have this problem, and got the correct answers from the beginning.
When compared to disk IO, I have not had a chance to compare mumps global speed vs Java or C disk IO, but in GT.M I can update 4,000,000 subnodes in 17 seconds. That is blazingly fast, but again, I have nothing to compare it against.
When compared as a database, SQL Server far outperforms Fileman. The general rule of thumb is that SQL Server is faster than Fileman by a magnitude of 4 to 1. I know that many people always say how "SQL Server and Oracle are slower than Fileman", but that is simply not true. My coworkers and I have used the exact same server with the same problem set, implemented in both Fileman and SQL Server, and run the same query to receive the same dataset. SQL Server outperforms Fileman, bar none.
In Fileman's defense, it is more than just a DBMS, it handles user IO, and has it's own programming API (date/time utilities, etc.).
Our next step will be to have a complete problem which requires a large database query, and number crunching as a cohesive unit. Perhaps then the Mumps model of tight integration will see an advantage as you can directly manipulate globals and Fileman from your code, whereas C or Java has to interact with SQL Server through ADO or ODBC.
I know I haven't posted numbers yet, but we have more testing that we'd like to do. I don't want to have anything indexed by google until I have a complete set of numbers to post at once in a coherent manner.
Subscribe to:
Posts (Atom)