Paper Title (use style: paper title)

AIS 2013 • 8th International Symposium on Applied Informatics and Related Areas • November 7, 2013 • Székesfehérvár, Hungary

Irisz Project: A Web Application for the Introduction of University Students to the Labor Market Gábor Kertész*, Éva Hajnal* *

Óbuda University Alba Regia University Center, Székesfehérvár, Hungary [email protected], [email protected]

Developing web applications for a large number of users is a complex problem: supporting different functions for different user types, having access control over user levels, having brief response times, and being prepared in web security questions. Creating a web-based software for thousands of university students is a special case, the load is not evenly distributed, and the authentication of students is critical.

I. INTRODUCTION Project Irisz is developed and hosted at the Alba Regia University Center (AREK), and its main purpose is to connect students with companies through various projects. There are multiple user-levels with different kinds of data, different logins, very complex database, huge load, and a need to create anonymous statistics about user actions. The idea behind Irisz is the need for bringing the industrial area, companies and start-ups closer to students at the University [1]. Almost every student require real projects for their skills, place and task for their thesis, internship, routine, future part-time or full-time job after getting their diploma. A great solution would be if the companies interested in hiring or co-operating with students could post project descriptions to a website made directly for this purpose, and targeted directly to these students. II.

FUNCTIONAL SPECIFICATION

Irisz is planned to connect the two main actors, “Students” and “Companies” through “Projects” (Fig. 1). The only connection between them is made exclusively through the “Projects”.

Figure 1. The main elements of Irisz

Pages are separated by the following point of view; the pages and functions should serve different users. For all user levels there is a possibility to register and log-on, a way to create, join and manage projects, find capable students or search for companies, to message, invite, hire students, or accept applications and follow up project life cycle until its end. User-levels are extended with a “Visitor” level of users who are only able to see the public content on the site. Visitors (or guests) can’t modify or create content, can’t interact with all kinds of users. They can only access public student profile pages and search for companies. Students can register and login, modify their own profiles, update it, add experiences and language skills. And of course if they’re interested in a project, they can apply for participation in it. The “Administrator” is a super-user who can help, moderate user profiles and manage levels of access. The Administrator has basic moderation opportunities, and he is also able to create and send newsletters directly to user groups. Companies should also be able to register and login, but on a different form: different information is needed from students and from companies. They will have their own profiles but with different structure. In summary: companies are producers of Projects and the Students are consumers. Beyond producing Projects the software has to provide an automatic function to search for potential students, invite them, and if a student has already applied, hire them. These are the main functions for different user-levels, but how do they work particularly? A. Registration, login The different levels are authenticated by different aspects: students have to be linked with the University – while there are a lot of companies, and for any company, at any time, the application needs to be opened. This means that student registration is not a simple process. It is a profile creation for those, who are certified as students (see Table I.). There is a system to identify students, it will be considered later. Company registration is filling an online form: a contact person gives contact information, name, e-mail address, telephone number, and – after normal

125


C. Experiences To make a centralized way to index experiences, the idea is that students when editing their own page, can add experiences as tags. When adding new tags, simply a link will be created in the database to the existing tag, or if the tag is new, it will be added. Experiences given on the profile creates an online CV for the student. As a student, these experiences will grow fast. While the profile is synchronized with current remarks, the finding of a project more likely is. This tagging will be used when a project is published: the company can associate experience tags to the project, so the students can be filtered more effectively.

TABLE I. DATA REQUIRED FOR STUDENT REGISTRATION Name

Type

Profile picture

File

Privacy setting

Select-option

Yes

Full name

Text

Yes

E-Mail

Text

Yes

Gender

Option

Yes

Birth date

Date

Yes

Permanent address

Text (City)

Yes

Phone number

Text

Driving license

Radio

Short introduction

Text area

Required

authentication of the e-mail – the profile is created as inactive. Inactive companies can’t use the application until they are activated: the activation process is done by the moderator (here Admin) with telephone or mail check through the contact person. B. Profile pages Students and companies have profile pages so they can view each other, but visitors can list active companies and students as well. When registering, all students have to enter some basic information, which cannot be changed later: name, birth date, and gender. Other information, such as e-mail address, phone number, introduction, profile picture etc. can be changed later. Company profiles are public: the name and basic information are visible. Before login we are able to see only the project names and numbers, but can’t look inside them: the description is private, only the owner company, and the registered students can reach this content. Student profiles can have four types of setup for privacy: - Public: student profile pages are public for everyone, including visitors. Private data such as e-mail address and telephone number are hidden. - Anonymous: student profile pages are public, but the name is replaced by the student identifier for the visitors. Only logged-in users can see the full name. - Hidden: student profile pages can be seen by authenticated users only, visitors cannot see them at all. - Private: with this setting the profile page isn’t visible for other students, only companies can see it. This privacy setting is asked at the registration form, but can be changed later on. E-mail address and telephone numbers are invisible on every page for all kinds of user types. With this setting, no-one will receive any unwanted e-mails. The main communication is restricted to the system’s mailing module.

D. Projects Projects are exclusively made by companies. An infinite number of projects can be made, it is not restricted. Each project has a name, and an employment number must be defined, which is a maximum number, but projects can be started with less applicants. Other required information are short description of the task, desired qualification, the type of project: thesis, training, cooperation, student job, part-time job, etc. Every project has a life-cycle (Fig. 2) consisting of four (three plus one) statuses: published, expired, in progress, finished. When a project is created, it is clarified as published, and it must stay published for enough time so students can apply on it. If the time is up, it changes to expired. A project can be started, if at least one applicant is hired: starting in this context means changing its status to “in progress”.

Figure 2. Sequence diagram of the project lifecycle

Application is allowed only if the project is published. After it expires, no more applications are allowed from students: however, the company can still hire the students, so the project can start after its application date expires (Fig 3.).

126


Application is a complex process, and needs to be clarified, and put into statuses: after a project is made and published, the student can visit and list the projects page, and apply on it. Student can be informed about the project by a direct message from the company. This is a so-called invitation, to join the project. Applications can require recommendations: these can be made by teachers. Teacher recommendations are only valid on a certain project. These can be asked by the student, when applying. The application isn’t done until the recommendation is given. After the student applies to the project, the company can accept that, or simply ignore it. If it is chosen to be accepted, the student is informed about it. And, the student can accept or refuse this: with this, every student has the opportunity to apply to multiple projects, and only have to join one. If the student accepts the employment, he becomes active on the published or expired project: please note it, that the student can accept this offer even after the project is expired. The only restriction is that a student can not apply on a project after it is expired: if the application is done when the project is in published state, the doublecheckout with company hiring and student accepting can happen in expired-state.

Figure 3. Status diagram of application lifecycle

If the project is not yet in progress, the student can be removed from the project, without any effects. However, if the project is already started, and the company believes that the student needs to be removed for some reasons, the process is called “dismissing”, and will leave a note on the student’s profile.

The same applies on the main project information: they can be freely changed until the project is in published state – note that the expiration date can’t be lowered below a limit. After expiration, the project can be republished, that means, the expiration date is renewed, and students can apply again. But after the project is considered as “in progress”state, none of its data will be modifiable: only the state can be changed to finished, but this can be done at any time, depends on the company’s decision. To achieve that projects will be finished at some point, a project starting and ending date should be given when publishing, next to the project publishing’s ending date. After the ending date is reached, the company will be asked to rate the student, and set the project status to be finished. E. Messaging Due to privacy policies, none of the users e-mail addresses will ever be given out, or will ever be published on the site. They will be handled in a closed system: emails will be sent out, if the student or company is affected in some sort of project change, or is messaged by another. Because messaging can’t be left out of an application involving jobs: the company and even the applicant might have questions: so a custom messaging module is needed. There are several rules, so this module won’t lose it’s main function: - A message has one sender, but can have multiple receivers. - Sender types are: System, Student, Company - Receiver types are: Student, Company - The sender type and the receiver type must be different for every message. With this rule, students can’t message students, and companies can’t contact other companies. - A student-company conversation can only start with a company letter. A student can’t message a company randomly: students can only respond to messages. Every message will be synchronized to the mailing account of the user: from every incoming message, an email will be received. Due to the massive load of outgoing mails, the server might get slow: to avoid this, a mailing queue needs to be created, so the sending can be balanced. F. Statistics To check the popularity of the application, and to provide correct statistical numbers, almost every user step, visitor, and data should be tracked. These numbers and logs could provide a great lesson to the developer when maintaining the software. Hopefully, this software will be able to serve companies and users without any need of major changes in it’s logic. A valuable function would be, if every nonmoderator related activities could be automatized.

127


III.

DEVELOPMENT

A. Data Model The functions described above are gathering around three main objects: Student, Company, and Project. Both Student and Company reaches Project, and Company can reach Students via messaging, invitation to project, or rating after the project is finished. The database – when talking about a web-application – should be a relational database. Other types are not transparent enough to serve a huge application like this. The relational databases can answer slowly when they contain huge amount of data: at this application this could be a real problem. To avoid this, the technologies should be chosen wisely, and communication between the database and the application needs to be extra-light. My choice is to use PHP technology with MySQL database, and thick JavaScript on the client-side, using AJAX technology to decrease loading times. B. Student authentication The Hungarian National Information Infrastructure Development Institute (NIIFI) created a system called EduID to identify uniformly every student, teacher and co-worker of various universities in Hungary [2]. Online worksessions based on this authorization method requires the same user name and password for all systems, for example: if a student or teacher of the Óbuda University wants to log in to the Neptun education system or the Moodle course management/e-learning system, they have to use the same user name and password. These passwords are stored only once, in the so-called ID Providers database; so in our applications database there is no need to store password, because the authentication is centralized. Irisz is based on this method, and gives us large user-base: everyone at the University can be the user of the software, without any kind of registration. There is no need to create authentication method for students, this will be done by the ID Provider. No need to store passwords: IDP handles this as well. EduID is very similar to Facebook Connect: although after logging in at the IDP the users will not be asked about possible data exchanging, like when using Facebook Connect. This is because there is an agreement between the Service Provider and the ID Provider that’s why the EduID system can’t be used by third party websites. A registration isn't enough to use this authentication method. Facebook Connect works via Facebook's Applications, EduID is based on SAML 2.0, a standard markup language developed specially for exchanging authentication information. A good approach is to use a module, which handles the functions needed: like SimpleSAMLphp [3], which is an object-oriented solution written in PHP. To merge this to an application a good layered system model is recommended.

C. Framework MVC pattern (Fig 4.) is just like this: Model, View and Controller are the three components[4]. “Model” stands for the database layer, which includes the connection to the database and every interaction with it: reading, writing, updating and deleting data. “View” consists of HTML, CSS and JavaScript: the user-side of the

Figure 4. The Model-View-Controller pattern

application, the so-called front-end. In the “Control” layer are the logic: this layer calls the needed Model functions and generates the content into the selected View. Model and Control are called the back-end. When developing Irisz, I chose to use a custom MVC code, written directly for this purpose. There are few existing MVC Frameworks written in PHP for this pattern, but they use a lot of code for functions which are not necessary needed: making it a bit slower. A custom code however will be faster, but everything the framework provides need to be coded: from page generation to security issues. First of all: URL [5] rewriting. This means, that using the HTTP protocol, access the IP behind the given hostname or domain name, reach its 80 port by default, find the mainly shared directory (when using Apache on Debian, this is the /var/www), open the subdir and give the site.html back to the requesting browser. When using PHP technology, this not as simple as giving back a file: the php file needs to be interpreted, and the output - which is in good case, HTML structured - is given to the browser. This URL is not nice enough with the .php ending. Another problem is, when using an MVC system, all requests must go through the Control: this means, everything must go through one file. To message this file, which page should be displayed, can be done by giving it a GET parameter via HTTP: http://hostname/control.php?page=main When niceness is an aspect, this is even worse. The best solution is to use URL Rewriting, a method which translates a nice URL to one, which can be handled. This can be done with .htaccess manipulation or Apache configuration. The second is difficult, because changes are to be made in a different syntax for every site and page. A lot better is, to get around this, and use PHP to handle nice URLs: a redirection is made in .htaccess, and every request is given to index.php, if the request is

128


trying to access a non-existing file or directory. The main file, index.php then gets the original HTTP request, and calls the suitable Control function to serve the browser correctly. IV.

CONCLUSION

The specified software is currently under development, however a beta version is already being tested by students of the Alba Regia University Center. The main functions such as EduID authenticated log-on, student profile editing, project listing and applying are fully operating. The modules for messaging and statistics are prepared to be launched in beta. It will be really exciting to see how events will turn out: a real milestone will be when a student successfully finds a project through Irisz, and hopefully this will happen soon. Under the solid pressure of the test-period, response times are looking fine. The following tests will include a heavy pressure test, and hopefully the application will tolerate the large number of simultaneous requests, too. Speeding up service is the main question of the forthcoming episode of development. The software was developed for the ~12 thousand students of Óbuda University and for nearly 100 companies. In the final phase we will measure the speed of this software in order to prove the ability of handling a lot of connections later. These are important factors in the success of this software just like the user friendly screens and promotions. This way the channeling of project management activities will be solved and we hope that this will turn out not as an anti-human project but a real help in bringing innovation into the Óbuda University.

V.

ACKNOWLEDGEMENT

The project was supported by TÁMOP-4.2.3.12/1/KONV „Alba Regia Egyetemi Központ tudományos eredményeinek disszeminációja, mérnöki és kutatói utánpótlás biztosítása a közép-dunántúli régióban” VI. [1] [2] [3] [4]

[5]

129

REFERENCES G. Kertész, É. Hajnal “IRISZ project specification”, unpublished Tamás, Frank “Indul az EduID bizalmi szövetség”, NIIF Hírlevél, IX. évf. 10. szám, November 2010. simpleSAMLphp, http://simplesamlphp.org 2013.10.20. T. Reenskaug “Models-Views-Controllers”, unpublished notes, http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html, December 1979 T. Berners-Lee, L. Masinter, M. McCahill Uniform Resource Locators (URL), RFC:1738, CERN, December 1994