Fiction from students or how to assemble a cross-platform social geolocation
Hello!
Today I want to talk about the good experience that we have in our university.
I have been teaching for almost 5 years and this year we went to the experiment. We (teachers) decided to introduce as an element of the assessment of the term paper on the subject - “public censure”. Those. students write a post for Habr on the subject of the course, and we follow the feedback and public discussion. This will not be a negative assessment (we must encourage our “valuable personnel”), however, it may not be a plus (if public censure reaches its climax). In general, the judges here are experts and users of the Habr. And, it seems to me, such an experience is useful for students - they will understand more deeply the problems of their work.
So, the first candidates: 3rd year students. Coursework in the discipline "Computer Graphics" (yes, we can also take interesting developments on this subject). I’ll make a reservation right away that we train engineers, not programmers. Although from our department already 15 people work in Yandex in various positions. And very successful. All project sources and links are at the bottom.
Here, in fact, the article itself (almost without corrections):
The idea of this service came to one of us suddenly when the question arose about the idea of term paper. We already had experience in creating a purely mobile application for Android OS, but after looking at the zoo of phone manufacturers and OS for them, we decided to try something new and we did it! The main essence of the project is that the user selects what he wants to visit in 3-4 clicks, selection criteria (price, availability) and the way of moving, and the application shows which places meet his criteria and draws routes.
The main audience of the service is lazy people, youth and people leading an active lifestyle and having accounts in social networks or / and having a phone with Internet access.
The main goal, from the very beginning, was to create a working mobile version and a PC version, only then came the idea to try yourself in an iframe for social networks.
Having examined a couple of applications for phones and their mobile versions, we developed common concepts for the service:
As well as the main functionality, the rest is already like features:
And we started to do it!
Scheme of the service
After selecting a topic and approving it, we started by drawing up a plan and finding development tools.
First of all, we needed a map, THIS IS A GEO SERVICE! We considered two platforms for maps - YandexMaps and GoogleMaps, the second one fell away immediately because of its bourgeois origin, bad Russian maps and an incomprehensible policy towards developers. We were not disappointed in the choice.
The beginning of our plan consisted of pumping a skill in web development and a smooth transition to the execution of functions - before that, none of us was actively involved in web development. Having come to the fact that the first mobile and pc versions, curves and crutches, can be rolled out in November, we distributed the responsibilities: for one - layout and js, php, for the other - php, YandexApi, mongodb. In the future, these duties were not particularly respected.
For the role of sub, we had two options: mongodb or mysql. We needed speed and scalability. Mongodb turned out to be more convenient and easy to use, especially since one of us had experience working with it. By the way, a separate article is devoted to our comparison of mongodb and mysql, which will be published a little later.
At the very beginning, we had a question: under what mobile browser do I make a mobile version? The choice fell on opera mobile, because of its prevalence on older phones and availability. But later it became clear that it does not support part of the js api of Yandex maps.
As you know, there are two versions of opera for mobile devices - opera mini and opera mobile. About their differences, you can read the section on the site .
Coordination is done by js, he knows how to do it according to the standard and without loading libraries, but sometimes funny moments happened: sitting at home from an inpatient through a router or in a cafe with a laptop, the service determined that the user was in the very center of Moscow, and specifically in Alexander the garden. If you enter from a mobile phone through 3g, then there will be a very large spread, one and a half in the house. And also because of the browser settings, the service sometimes did not find the user. To fix these jambs, we introduced the function of manually entering the address in case of unsuccessful determination of coordinates.
About the problems that we had with the opera.
After downloading the PC version to the hosting, the development of the version for mobile phones began. After creating the mobile version, uploading it to hosting and launching it in opera, we were pleasantly surprised that the opera does not support the js part, we discovered this with android samsung GT-S5830 and in symbian. At the first test of the mobile version - the route was not displayed on the map, although if the same mobile chrome - it draws everything.
Parsers we filled the database with information on cinemas and museums. The main task is to implement a parser that will spin on CRON and update our database (once a day). The parser consisted of regulars, standard php functions and libraries ... for working with the DOM and ..., which is used to translate a text address into geographical coordinates. You can see the implementation of both parsers here.
We did not have experience developing an iframe for social networks, but having tried it, we realized that vk has a very strange api, namely two versions and few examples, either they were too lazy, or they decided that it was not advisable yet, but this is sad. In contrast, mail.ru api has many examples and good documentation.
When developing the service, we used several algorithms for issuing the nearest objects on the map, for museums and cinemas, as well as for user events, which are mainly based on queries to the database.
For example: to search for the 5 closest movie theaters, we use the query mongod db.cinemas.find ({“geo”: {$ near: [x, y]}}. Limit (5), initially setting up indexing in the database with the db command. cinemas.ensureIndex ({“geo”: “2d”, type: 1}).
Our events are designed for joint time, therefore we issue the next events in a radius of 2 km. After the event ends, it is automatically deleted from the database.
Events in our service can not be compared with foursquare events, since people just pick it up in foursquare, and, as described above, they pick it up with a view to sharing time, and we also collect more detailed information, and not just the user's nickname and its place, namely: user contacts, event name, event date, you can also specify the site url for advanced events.
About two months we worked and tested locally, but soon there was a need for hosting, for a long time we could not find a suitable host with a working mongodb, in the end we found it, a link to it below.
We had to abandon the self-written xmlrequest, due to the fact that mobile browsers may not support this technology in full.
What we used when developing
git
phpshtorm
eclipse
mongodb
YandexAPI
Hosting: https://locum.ru/
Differences opera mobile from opera mini http://en.opera.com/mobile/specs/
Framework http://twitter.github.com/bootstrap/index.html
Sources https: / /bitbucket.org/ziganzigan/habrcode
mail js API
VK api The
page of the project itself .
Today I want to talk about the good experience that we have in our university.
I have been teaching for almost 5 years and this year we went to the experiment. We (teachers) decided to introduce as an element of the assessment of the term paper on the subject - “public censure”. Those. students write a post for Habr on the subject of the course, and we follow the feedback and public discussion. This will not be a negative assessment (we must encourage our “valuable personnel”), however, it may not be a plus (if public censure reaches its climax). In general, the judges here are experts and users of the Habr. And, it seems to me, such an experience is useful for students - they will understand more deeply the problems of their work.
So, the first candidates: 3rd year students. Coursework in the discipline "Computer Graphics" (yes, we can also take interesting developments on this subject). I’ll make a reservation right away that we train engineers, not programmers. Although from our department already 15 people work in Yandex in various positions. And very successful. All project sources and links are at the bottom.
Here, in fact, the article itself (almost without corrections):
The idea of this service came to one of us suddenly when the question arose about the idea of term paper. We already had experience in creating a purely mobile application for Android OS, but after looking at the zoo of phone manufacturers and OS for them, we decided to try something new and we did it! The main essence of the project is that the user selects what he wants to visit in 3-4 clicks, selection criteria (price, availability) and the way of moving, and the application shows which places meet his criteria and draws routes.
About service
The main audience of the service is lazy people, youth and people leading an active lifestyle and having accounts in social networks or / and having a phone with Internet access.
The main goal, from the very beginning, was to create a working mobile version and a PC version, only then came the idea to try yourself in an iframe for social networks.
Having examined a couple of applications for phones and their mobile versions, we developed common concepts for the service:
- Ease of usability.
- Deeper personalization to extradition.
- Availability
As well as the main functionality, the rest is already like features:
- Issuance on the map of cinemas, museums and user events.
- Cinema timetables.
- Search for a movie and issue the nearest cinema, where it can now be viewed based on the time and location of the user.
- Custom events.
- Making a route from the current location of the user to the selected object.
And we started to do it!
About development
Scheme of the service
After selecting a topic and approving it, we started by drawing up a plan and finding development tools.
First of all, we needed a map, THIS IS A GEO SERVICE! We considered two platforms for maps - YandexMaps and GoogleMaps, the second one fell away immediately because of its bourgeois origin, bad Russian maps and an incomprehensible policy towards developers. We were not disappointed in the choice.
The beginning of our plan consisted of pumping a skill in web development and a smooth transition to the execution of functions - before that, none of us was actively involved in web development. Having come to the fact that the first mobile and pc versions, curves and crutches, can be rolled out in November, we distributed the responsibilities: for one - layout and js, php, for the other - php, YandexApi, mongodb. In the future, these duties were not particularly respected.
For the role of sub, we had two options: mongodb or mysql. We needed speed and scalability. Mongodb turned out to be more convenient and easy to use, especially since one of us had experience working with it. By the way, a separate article is devoted to our comparison of mongodb and mysql, which will be published a little later.
At the very beginning, we had a question: under what mobile browser do I make a mobile version? The choice fell on opera mobile, because of its prevalence on older phones and availability. But later it became clear that it does not support part of the js api of Yandex maps.
As you know, there are two versions of opera for mobile devices - opera mini and opera mobile. About their differences, you can read the section on the site .
About the clumsiness of determining coordinates
Coordination is done by js, he knows how to do it according to the standard and without loading libraries, but sometimes funny moments happened: sitting at home from an inpatient through a router or in a cafe with a laptop, the service determined that the user was in the very center of Moscow, and specifically in Alexander the garden. If you enter from a mobile phone through 3g, then there will be a very large spread, one and a half in the house. And also because of the browser settings, the service sometimes did not find the user. To fix these jambs, we introduced the function of manually entering the address in case of unsuccessful determination of coordinates.
About the problems that we had with the opera.
After downloading the PC version to the hosting, the development of the version for mobile phones began. After creating the mobile version, uploading it to hosting and launching it in opera, we were pleasantly surprised that the opera does not support the js part, we discovered this with android samsung GT-S5830 and in symbian. At the first test of the mobile version - the route was not displayed on the map, although if the same mobile chrome - it draws everything.
About Parsers
Parsers we filled the database with information on cinemas and museums. The main task is to implement a parser that will spin on CRON and update our database (once a day). The parser consisted of regulars, standard php functions and libraries ... for working with the DOM and ..., which is used to translate a text address into geographical coordinates. You can see the implementation of both parsers here.
About apivk and mailapi
We did not have experience developing an iframe for social networks, but having tried it, we realized that vk has a very strange api, namely two versions and few examples, either they were too lazy, or they decided that it was not advisable yet, but this is sad. In contrast, mail.ru api has many examples and good documentation.
About Algorithms
When developing the service, we used several algorithms for issuing the nearest objects on the map, for museums and cinemas, as well as for user events, which are mainly based on queries to the database.
For example: to search for the 5 closest movie theaters, we use the query mongod db.cinemas.find ({“geo”: {$ near: [x, y]}}. Limit (5), initially setting up indexing in the database with the db command. cinemas.ensureIndex ({“geo”: “2d”, type: 1}).
activity
Our events are designed for joint time, therefore we issue the next events in a radius of 2 km. After the event ends, it is automatically deleted from the database.
Events in our service can not be compared with foursquare events, since people just pick it up in foursquare, and, as described above, they pick it up with a view to sharing time, and we also collect more detailed information, and not just the user's nickname and its place, namely: user contacts, event name, event date, you can also specify the site url for advanced events.
Development issues
About two months we worked and tested locally, but soon there was a need for hosting, for a long time we could not find a suitable host with a working mongodb, in the end we found it, a link to it below.
We had to abandon the self-written xmlrequest, due to the fact that mobile browsers may not support this technology in full.
What we used when developing
git
phpshtorm
eclipse
mongodb
YandexAPI
References
Hosting: https://locum.ru/
Differences opera mobile from opera mini http://en.opera.com/mobile/specs/
Framework http://twitter.github.com/bootstrap/index.html
Sources https: / /bitbucket.org/ziganzigan/habrcode
mail js API
VK api The
page of the project itself .