You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 21, 2018. It is now read-only.
@Yurockkk , @zeivhann and me all started working on getting our different android utilities working with in an actual application. The process is starting to reveal just how long this will take to complete.
A new repository was made today to partially organize all of our different coding projects that will eventually be merged together to create the OLE Utility app. You can find them here. Please use this if you need to refrence current projects or if you need to update the team on a project you are working on.
@leonardmensah Has made significant changes to the Take-Home applications UI. We would like everyone to test it. you can find it here (make sure you are on the maxi_ui branh). Mess around with it. If you find any thing that could be changed or improved to the UI, sugesst it to the original issue..
@Chris-Boe and @navneetkarnam both wanted to start contributing to the team in some way. I have suggested that they start reaseaching and implementing zipped html resources for Take-Home. It was suggested that that this process can be done in 2 ways:
Have them zipped on demand. User request an HTML app, MongoDB runs a script and zips the app, then sends it over.
Have the HTML apps Pre-zipped. When a user adds an HTML app to the MongoDB, a script runs and zips the app. User request the HTML app, MongoDB sends over the zipped app.
Proposal 1 has the advantage of developers not needing to change the way they add HTML apps to the DB, along with saving space. The disadvantages includes more CPU overhead in the field. I don't know if the size of the apps would cause a problem in having them zipped on demand, but it is something to consider.
Proposal 2 has the advantage of having all the processing done at time of adding the app, thus relieving the computing time in the field. This cause an inflation of space server side. I don't know if that is a problem, but this way i would think would be optimal for people in the field.
Last Week: #67
In todays meeting, Me, @leonardmensah, @zeivhann , @Yurockkk , @Chris-Boe and @kanishk1010 all met and talked about what we were working on.
@Yurockkk , @zeivhann and me all started working on getting our different android utilities working with in an actual application. The process is starting to reveal just how long this will take to complete.
A new repository was made today to partially organize all of our different coding projects that will eventually be merged together to create the OLE Utility app. You can find them here. Please use this if you need to refrence current projects or if you need to update the team on a project you are working on.
@leonardmensah Has made significant changes to the Take-Home applications UI. We would like everyone to test it. you can find it here (make sure you are on the maxi_ui branh). Mess around with it. If you find any thing that could be changed or improved to the UI, sugesst it to the original issue..
@Chris-Boe and @navneetkarnam both wanted to start contributing to the team in some way. I have suggested that they start reaseaching and implementing zipped html resources for Take-Home. It was suggested that that this process can be done in 2 ways:
Proposal 1 has the advantage of developers not needing to change the way they add HTML apps to the DB, along with saving space. The disadvantages includes more CPU overhead in the field. I don't know if the size of the apps would cause a problem in having them zipped on demand, but it is something to consider.
Proposal 2 has the advantage of having all the processing done at time of adding the app, thus relieving the computing time in the field. This cause an inflation of space server side. I don't know if that is a problem, but this way i would think would be optimal for people in the field.
See you next week.
Next week: #72
The text was updated successfully, but these errors were encountered: