Hackpads are smart collaborative documents. .
905 days ago
2 / 4
Unfiled. Edited by Jaakko Korhonen , Molly Schwartz 905 days ago
  • Use commenting to suggest additions and have a free, open and critical discussions in between the text chapters.
  • COSS description, Timo V / Moona
Feasibility Study on Service Solution Architecture, Open Source Software Components and Developer Communities. This document works as a design document for further Open Journey Planner development.
919 days ago
Unfiled. Edited by Jaakko Korhonen 919 days ago
Agile procurement and Lean development
Lean development methods prefer to steer the development through guidelines and principles rather than specification documents. In this way developers are empowered to maximise their creative input to the project. Iterative development process is built on Refactoring Application Interfaces, Data and Software Code. The ever-changing software base requires a Component architecture that is Built to change. Developer should always be ready to rewrite a component from scratch, component by component at a time. With major version number change, data cycle requires the whole system to be changed into a new environment overnight.
Developer Community Engagement Methodology
Developer community and management of the Open Source Project is built on the fact that open community enables software developer engagement on several levels: through peer support, co-creation and shared problem solving, innovation is quicker and recruitment easier than with some other development models.

857 days ago
8 / 8
Unfiled. Edited by Jaakko Korhonen 857 days ago
  • If control on the Open API environment needs to be excerted, a API key, i.e. automatically assigned token can be configured, such as http://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication Tokens should be available with automated  assignation 24/7 for the API to still comply wit opendefinition.org principles. A web page where email is reqiested and token sent to that email for use in application-specific access should suffice to most scenarios. In this way control and blocking can be excerted API key -specifically.  Helsinki City uses server firewall blacklisting, but otherwise opens the API:s fully, and problems haven't appeared as of yet.
  •  
857 days ago
2 / 2
Unfiled. Edited by Jaakko Korhonen 857 days ago
@ Töölön toimisto, Caloniuksenkatu 9 D 64, organized by Open Knowledge Finland https://www.facebook.com/events/1432124003758513/
857 days ago
Unfiled. Edited by Dennis Kreminsky 857 days ago
Basic stress testing performed with `ab` tool from Apache Foundation.
875 days ago
Unfiled. Edited by Jaakko Korhonen 875 days ago
Ohryyn kutsuttu
Tomi.Lapinlampi@liikennevirasto.fi
Tuukka Hastrup  (Tuukka.Hastrup@hsl.fi)
Thomas Casey (thomas.casey@vtt.fi)
jouni@sipuligroup.com
tuukka.puranen@nfleet.fi
lauri.sukselainen@solita.fi
Veijo Aalto  (veijo.aalto@student.hamk.fi)
msp@ee.oulu.fi
905 days ago
2 / 4
Unfiled. Edited by Molly Schwartz 905 days ago
  • Use commenting to suggest additions and have a free, open and critical discussions in between the text chapters.
  • COSS description, Timo V / Moona
Feasibility Study on Service Solution Architecture, Open Source Software Components and Developer Communities. This document works as a design document for further Open Journey Planner development.
905 days ago
0 / 2
Unfiled. Edited by Molly Schwartz 905 days ago
  • Use commenting to suggest additions and have a free, open and critical discussions in between the text chapters.
  • Use Cases
Services are developed to address human needs. For example, the development of Journey Planner software services are designed to help users navigate a route from where they are (Point A) to where they want to go (Point B) using the most efficient and most convenient public transportation options available. Therefore, the creation of technical route-planning solutions should be informed and inspired by user stories. The non-technical descriptions of how users want and should be able to deploy services are called user stories. These user stories include multiple discrete steps and components, such as user needs, feature definitions, and solutions, which are called functionality modules. These non-technical descriptions of functionality modules are oftentimes consistent and repeated across different user stories, and therefore they are reusable. The functionality descriptions below provide non-technical descriptions of functionality modules that can be defined and reused across and different user stories in order to fulfill user needs in an efficient, interoperable design
905 days ago
0 / 2
Unfiled. Edited by Jaakko Korhonen 905 days ago
  • Use commenting to suggest additions and have a free, open and critical discussions in between the text chapters.
  • Principles
Architectural development principles are used as basis for making design choices when developing a new web service. Architectural principles have been adjusted to accommodate decentralized open source development, dispersed piloting and lean software development methodologies.

Stop sharing the collection with ?

This pad is open to "", so will still be able to access it.
Cancel
Sujuvuusnavigaattori Feed

Contact Support



Please check out our How-to Guide and FAQ first to see if your question is already answered! :)

If you have a feature request, please add it to this pad. Thanks!


Log in