Concluding the course today, we all have to review a bit, as well as present, what is done on shareTime.
Our work-group is composed of three totally different people, thats for sure. Let's not blame ourselves for what ended behind expectations, but we have to do a little review. Kudos to Jara for what he has done, he succeeded the task of migrating whole structure from glassfish server to appengine, good job really! We can rely on current state and build a really nice and useful app in the future. What is done on the project works just nice, but a scarecrow is pending in our heads, because not everything we wanted to show up is ready now. On the server side, we do not have adding new events done, which is holding two screens out of usage, even meaning they stay completely blank at the moment.
But I spent quite some time working on shareTime last week or two and I must say I came up with some thoughts and ideas here and there. For example, why not to allow the users to make a poll about when should a new activity take place - I mean, what about implementing a doodle voting for activities with undecided constraints? And what about each user could add a confirmed activity to his google calendar just automatically? That is not just for us to decide, whoever reads this blog can leave a comment below, I can assure you we will keep feedback in mind
Pavel
čtvrtek 22. prosince 2011
středa 14. prosince 2011
MVP Delirevable today
Fall of the semester is here and we are about to deliver, what's done. Since Jara did an amazing amount of work, me and Emil were trying to carry some more updates recentely. I have been coding the last two days, but unfortunately can not commit and deploy my present state to our SourceForge repository.
Questioning minimum viability of the project, I must say with updating the schedule and inviting friends to a new activity - which is what i have been working on recentely - we are there.
May it seem foolish, I hope there can be some chance of running out of time at the class today, where other teams will step up with their presentations. I cheer for them, would their work be interesting, meaning us possibly given the chance to present next week, we would manage to settle some nice updates and tweaks which are close to be done, but for some reasons, I am unable to bring them alive just right now.
I just hope our effort from the very last days will have some impact, no matter when we will be showing up the app.
Pavel
Questioning minimum viability of the project, I must say with updating the schedule and inviting friends to a new activity - which is what i have been working on recentely - we are there.
May it seem foolish, I hope there can be some chance of running out of time at the class today, where other teams will step up with their presentations. I cheer for them, would their work be interesting, meaning us possibly given the chance to present next week, we would manage to settle some nice updates and tweaks which are close to be done, but for some reasons, I am unable to bring them alive just right now.
I just hope our effort from the very last days will have some impact, no matter when we will be showing up the app.
Pavel
úterý 13. prosince 2011
Running out of time
Hence the final presentations has to be shown on thursday morning, me and Emil met in Karlovo náměstí to focus on what's not done yet. You can find us in the E building of CTU, KN:E-2a to be concrete. At the moment we are starting our planned goal, which is to implement schedule functionality, which in detail means we want our activity sharing to be functional and to be shown to the friends, as well as in your own time schedule in our application. Lets hope we will find ourselves able to succeed.
Pavel and Emil
Pavel and Emil
neděle 11. prosince 2011
Our Progress
We have functional code that we will present on thursday. Jara made great effort to change server side from glassfish server to GAE. A lot of testing and progress has been done. We have server side deployed on GAE for about two weeks, it seems running very well with no complications. The difficult part was to change the database to the GAE philosophy so that it would work properly.
We also created user interface for samusng tablet. It is very simple and not so sophisticated yet but it is sufficient environment for further testing and development. It is also sufficient for our final presentation and working functionality demonstration. We will improve the interface in the future, we want that it looks much nicer with bigger icons. The good thing is that the application is connected to the gravitation sensor and it works OK.
Another difficult goal that has been achieved is communication with the server side on GAE with android client. Now the application communicates properly with the server and we have a basic functionality to demonstrate. We can log in to the application, all icons are in function and it is possible to create an event that you want to share with your friends. The next thing we need to do is just to share the event. We have not implemented it yet because we are running out of time at the busy end of the semester.
Everything is prepared including server side, database and communication and we will try to write final procedures to share the events between friend.
We also created user interface for samusng tablet. It is very simple and not so sophisticated yet but it is sufficient environment for further testing and development. It is also sufficient for our final presentation and working functionality demonstration. We will improve the interface in the future, we want that it looks much nicer with bigger icons. The good thing is that the application is connected to the gravitation sensor and it works OK.
Another difficult goal that has been achieved is communication with the server side on GAE with android client. Now the application communicates properly with the server and we have a basic functionality to demonstrate. We can log in to the application, all icons are in function and it is possible to create an event that you want to share with your friends. The next thing we need to do is just to share the event. We have not implemented it yet because we are running out of time at the busy end of the semester.
Everything is prepared including server side, database and communication and we will try to write final procedures to share the events between friend.
Most time-consuming activities
Before achieving some goals we spent a lot of time and we had to do a lot of I would say black work which looks really useless and nearly no progress can be seen. But it takes a lot of time to start up projects and projects environment on all developers machines. We tried to migrate our GAE server part to maven, we had to agree on all used technologies and finally debug written codes and start the application on Samsung tablet.
středa 9. listopadu 2011
Persistence progress and unit testing
Our hesitation and voting about technology for persistence layer is over. There are two possibilities: stay on JPA or use JDO. JDO is better documented in Google documentation for App Engine. JPA is often used in many other project and is widespread. We doubted, whether JPA is right technology for us. I have read a few discussions on this theme, where JDO is recommended. I had problems with JPA configuration on the start of our project, it was second cause for doubt. But now it's obvious, it doesn't matter on technology, but only on skill. You can choose based on your personal preferences. We stayed on JPA and it looks like a right thing.
Many time was spent on project back-end design resolving. App Engine philosophy for persistence is simple and straightforward, but its not so ease change existing project. At first we had to embrace this philosophy and throw away relationships in database. Realy we don't need them any more, because we can't use them in Big Table. As well owned one-to-many relationships are problem, we need one Entity Group for like relationships.
I find nice data type Key for App Engine Datastore primary key, with this primary key type we can simulate many-to-many relationship. We are planning to look on EntityGroup for our owned relationships usage, it's not so good documented for JPA, it could be complication.
Last interesting thing I put to our project is JUnit for testing. Now we can develop in test driver way. It looks App Engine is very friendly for unit testing. There is many mock objects for mocking Datastore, Blobs, Memcach and etc. It's nice. Now I started with persistence testing. It works great and my colleagues have available examples, how to start with testing. I see it like a most important asset in project for this week.
Many time was spent on project back-end design resolving. App Engine philosophy for persistence is simple and straightforward, but its not so ease change existing project. At first we had to embrace this philosophy and throw away relationships in database. Realy we don't need them any more, because we can't use them in Big Table. As well owned one-to-many relationships are problem, we need one Entity Group for like relationships.
I find nice data type Key for App Engine Datastore primary key, with this primary key type we can simulate many-to-many relationship. We are planning to look on EntityGroup for our owned relationships usage, it's not so good documented for JPA, it could be complication.
Last interesting thing I put to our project is JUnit for testing. Now we can develop in test driver way. It looks App Engine is very friendly for unit testing. There is many mock objects for mocking Datastore, Blobs, Memcach and etc. It's nice. Now I started with persistence testing. It works great and my colleagues have available examples, how to start with testing. I see it like a most important asset in project for this week.
pátek 4. listopadu 2011
Initial commit
Greeting for all readers! Our project is about sharing free time activity between friends and personal time management. We are in point, we have some functional basis of Android app and GlassFish based server side. Nowadays we decide migrate server part of project on Google App Engine infrastructure.
We implemented our first version of project based on AppEngine and moved from GlassFish. It was our first important step to cloud based server side of project. We are very excited and enthusiastic. Our next step would be composition of work done with our Android part of project.
If it looks like triviality to migrate from JPA basis on another technology or application server, but it wasn't. A lots of unexpected problems appeared. At first we decided to incorporate logging to out project. Log4j is very good choice, but it did not work for one day. The reason was comic, I badly configured log4j.properties file. One letter was forgotten in configuration for specific package logging: log4j.category. It was case when on one letter depends.
Second complication was quite similar, my configuration for persistence unit was wrong. File name persistance.xml with other letter substituted was big and curious problem.Exception thrown on that mistake was matchless and only logging saved me from fail during migration.
Finally we have GWT basis for client code, partly working persistent tier and native android client code. Our next steps should be put together AppEngine and Android. Second goal is upgrade of server side features and enable full functionality we had on GlassFish. There are some complications with ManyToMany and owned OneToMany relationships in BigTable. We are evaluating possibility of creation GAE part of project on Maven. Testing, automatic build and integration testing as well as adding library and dependencies for project are easy and cheerful with Maven.
Přihlásit se k odběru:
Příspěvky (Atom)