Kiri, Bang!

[kiribang]

sprint log #6

For this sprint review, I will focus more on the development method used in this Ngangkot project. We used Scrum, which is an agile software development process model. Agile software development processes follow points in the agile manifesto, which contains valuing individuals and interactions, working software, customer collaboration and response to change.

From what I saw so far, there had been less progress at points when we do not value each member and interactions between them. At the first sprint there had been problems due to not a lot of meeting and coordinating. However, when we intensify the meeting and collaboration, we can achieve more.

Our focus is, however, always on developing software that does well functionally. Even though we’re doing that by steps, I can say that we’re almost there.

There hadn’t been a lot of customer collaboration due to not much interaction with the stakeholders, though. So our response to change is mainly based on constraints of time and available tools—such as redefining the minimum viable product requirements and reproducing the product in different frameworks (for example, from native Android Studio to React Native).

Scrum itself is an agile framework for developing and sustaining complex and adaptive products. Our product is complex enough that we are not going to develop it in one go, and it is also adaptive to change, though from how we ideated the project and how we had not much communication with the client, there are not much major changes happening. We take the part as a development team—which is both self-organizing and cross-functional.

On Scrum development are done in sprints. One sprint in this subject is around one month long. Before each sprint, there is a sprint planning session to define required work to be done in the sprint, in form of product backlogs and tasks. At this sprint planning, we also determine how difficult a backlog will be according to our team’s decision.

Before the first sprint planning, we define a project vision—which contains the description of our product, its target audiences, the data, information and contents that it will need and the partners of the project.  This was done with an ideation process.

Through each of the three sprints, twice a week, we held a Scrum meeting to communicate progress and convey information related to the. Having a meeting, with recently also having weekly milestones, had helped on holding a sustainable development. It also helped on reflecting how to be more effective with the remaining time we have.

Along with Scrum (which is agile), we also use test-driven development. This process is achieved with writing automated test scripts before writing the software code. The advantages are we will know what to make to adjust with the test, we don’t have to run the code first if there is an error in the testing, which saved time, even though passing the test does not mean it will run correctly.

-Ghinaa

[kiribang]

Sprint log #6 - Agung

It is nearing the end of Ngangkot development process. This is my first time participating in a true software development team. To look back, I’ve learned quite a bit on the process.

We are using scrum—an Agile development process with twelve principles documented here. My first time looking at those principles (the fluid nature of the requirements, to be particular), my first thought was: ‘wow, that sounds like it would result in a chaotic development process’. And it does! These past few months were a kind of controlled chaos.

We were scrambling for the continuous deliverance asked by the Agile principles. Meeting a few times a week, changing our approach to problems and even modifying the requirement itself once we found better ways to accomplish our project vision. Now, I can’t imagine my team members doing this project using another development process.

Test driven development is another concept promoted by Agile. At first, it was quite a chore to write those unit tests. But now with the power of hindsight, it actually saved the team of untold amount of grief. Those tests actually caught a lot of bugs that the team wouldn’t have noticed until farther down the development process. It means that for each sprint the number of bugs accumulated would be smaller and it won’t be such a big punch to the face when they did appear to pose a problem.

[kiribang]

Sprint log #6 -kabul

In this project, we use agile software development which i haven’t talked about in any of my post, so in here I’m trying to explain more about the fundamental concept of it.

Agile Software Development is a term used to define a set of methods and practices based on the values and principles expressed in the Agile Manifesto. 

The Agile Manifesto itself have four core value, which are

- Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan

While we try to apply these value into our development progress, there are points that we can’t fully utilize, such as the third point, on Customer collaboration over contract negotiation. Since we don’t have a lot of interaction with the client, there are minimun change in user stories and requirement. So the change that we adapt to is the one that is limited by time constraint instead of a dynamic user requirement that would change overtime as it would be in real-world routine.

The 12 Principle behind the Agile Manifesto are

1  Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2  Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3  Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4  Business people and developers must work together daily throughout the project.

5  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6  The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7  Working software is the primary measure of progress.

8  Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9  Continuous attention to technical excellence and good design enhances agility.

10  Simplicity--the art of maximizing the amount of work not done--is essential.

11  The best architectures, requirements, and designs emerge from self-organizing teams.

12  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

On the application of the 12 Principles mentioned above we faced the same obstacle at the 2nd and 4th principle. Our development scenario allow us to work with a relatively static requirements. The 6th principle is implemented in the form of daily meeting which held 2 times a week. We apply the 1st, 3rd, and 7th principle by giving an output of deliverables in the form of a software on every end of sprint cycle. The 12th principle is also utilized at the end of the every sprint on the retrospective session.

We use Scrum as a process framework to manage product development. Development is divided into 2-4 weeks (4 in our case) cycle. These cycle is then called sprint. On sprint planning, product backlog thats going to be worked on is moved into sprint backlog and expected to be done by the end of the sprint. During the cycle, daily scrum is held so the team coordinates their activities for the following day.  At the end of the sprint, there is a sprint review where the entire team reviews the results of the sprint with stakeholders of the product. After that, on sprint retrospective the team should reflect upon how things went during the previous sprint and identify adjustments they could make going forward.

We still have a long way to go in order to fully employ the Scrum and Agile Manifesto. But the course have help tremendously to be agile, which defined as the ability to create and respond to change in order to succeed in an uncertain and turbulent environment. With these knowledge we can hopefully continue to improve ourself.

[kiribang]

Sprint log #6 - Drianka

Berhubung ini adalah sprint terakhir dari kelompok kami, untuk mempercepat waktu penulisan saya akan memakai bahasa indonesia. Selanjutnya akan saya jabarkan poin-poin dan aktifitas penting selama saya mengerjakan Ngangkot ini sesuai poin yang ada pada lembar learning progress mata kuliah PPL. Silahkan klik post ini untuk melihat keseluruhannya.

Project visibility and idea

Seperti yang sudah diketahui, kami membuat sebuah aplikasi bernama Ngangkot yang memberikan solusi bagi permasalahan operasional yang sering menjadi penyebab terjadinya macet di jalan raya: mengetem

Solusi ini kami tuangkan dalam sebuah aplikasi android yang ditujukan bagi penumpang dan pengemudi. Aplikasi Ngangkot diperuntukkan sebagai perantara bagi penumpang yang ingin menggunakan angkot serta supir angkot, memberikan informasi lokasi tunggu si penumpang serta lokasi keberadaan angkot saat ini dengan harapan transaksi(dalam hal ini naiknya penumpang ke dalam angkot) akan berlangsung lebih efektif jika sang supir tahu calon penumpang nya ada dimana saja dan penumpang akan terbantu dengan mengetahui kondisi angkot yang ia naiki saat ini ada dimana.

Perlu diperhatikan bahwa transaksi yang terjadi saat ini mengharuskan si penumpang menunggu di suatu tempat dalam durasi waktu yang cukup lama sampai angkot yang ia tunggu terlihat dalam pandangan, atau si pengemudi angkot menunggu di suatu tempat dalam durasi waktu yang lama dengan harapan penumpang yang menaiki angkotnya lebih banyak (dengan kata lain, menunggu penumpang naik). Hal kedua dapat menyebabkan terjadinya kemacetan jika tidak diatur lokasi penungguan oleh otoritas setempat. Berangkat dari kedua hal tersebutlah aplikasi Ngangkot ini diciptakan.

Tentunya masih banyak variasi solusi yang dapat diberikan dan diintegrasikan dalam aplikasi Ngangkot ini, namun dengan keterbatasan waktu pengembangan selama 3 bulan beserta melihat kondisi tim developer saat ini, kami memutuskan untuk membatasi fitur (dalam high level) pada hal-hal berikut:

Kebisaan penumpang untuk memilih dan melihat lokasi angkot melalui peta digital

Kebisaan pengemudi angkot untuk melihat penumpang potensial melalui peta digital

Dengan dua acuan tersebut, kami memecah dan mendetilkan lagi fitur tersebut dalam user story yang menjadi backlog kami dalam 3 bulan masa pengembangan.

berikutnya, saya akan membahas metode development yang kami pakai

##Agile framework, Scrum & Test-Driven development

Dalam pengembangan, kami menggunakan varian dari metodologi Agile serta pengembangan Test-Driven. Apa maksud dari dua istilah tersebut?

Agile adalah kerangka kerja pengembangan software yang memberikan perhatian khusus pada ketidakpastian requirement dan teknologi, serta merangkul perubahan dalam mengerjakan suatu proyek pengembangan software. Dalam definisi formalnya, Agile mengharuskan terjadinya development cycle (seperti gambar diatas) yang intinya terdiri dari siklus proses planning-pengembangan-evaluasi sehingga aplikasi yang dibuat dapat terus relevan dengan permasalahan yang mungkin saja bertambah atau berganti sesuai waktu berjalan.

Dalam proyek ini, kami menggunakan salah satu implementasi Agile yaitu metodoologi Scrum.

Scrum merupakan realisasi dari kerangka kerja Agile yang menggunakan instrumen backlog sebagai alat ukur kerja dari para pengembang. Selengkapnya tentang scrum dapat dilihat di sini

Selain itu, Agile juga mempunyai nilai-nilai yang menjadi prinsip bagi implementasinya yang dapat dilihat disini sini.

Dalam implementasinya, kami menerapkan scrum dan Agile dibantu oleh asisten dosen yang bertugas sebagai scrum master. Kami membuat backlog, menjalankan scrum planning,meeting,serta retrospective, dan menjalankan best practice lainnya yang akan menjadi topik bahasan selanjutnya

Continous Integration(CI) & Continous Delivery (CD)

Continous Integration & Continous Delivery adalah praktik kerja yang bersinergi dengan prinsip-prinsip Agile yang kita implementasikan dalam pengembangan Ngangkot. CI dan CD sendiri bukan merupakan hal baru dari dunia pengembangan software, namun merupakan hal yang baru bagi kami.

CI merupakan praktik kerja yang mengedepankan otomatisasi dari proses build,test, & deploy yang menjadi konsekuensi dari implementasi Agile. Hal ini dibisakan dengan menggunakan repository remote terpusat yang menjadi codebase utama bagi Ngangkot, mewajibkan seluruh kode yang dibuat diletakkan ditempat tersebut.

Dalam mengaplikasikan CI, kami baru 99% berhasil mengimplementasikan otomatisasi build & test, untuk deployment kami masih belum benar dalam mengimplementasikannya karena masih mengandalkan alur kerja yang salah.

CD merupakan prakktik kerja yang merupakan lanjutan dari praktik CI. CD mengharuskan adanya otomatisasi pengantaran software hasil pengembangan ke pengguna, yang menyebabkan setiap update dapat langsung di kirimkan ke aplikasi pengguna sebagai konsekuenasi dari CD itu sendiri beserta CI.

Seperti yang telah disebutkan diatas, kami masih belum benar menjalankan hal ini karena masih mengandalkan fitur download artefak dari gitlab CI pipeline, yang kurang intuitif bagi user.

Current work alert

Saya sedang berusaha membuat server yang dapat melayani permintaan download APK dari user dengan menggunakan Node.js + Express + Google drive API di platform Heroku. Sebelumnya kami menggunakan Postgre sebelum berpindah ke Google Drive API, namun ternyata Postgre-nya Heroku tidak melayani penyimpanan Large Object

Maka, pembuatan server ini masih WIP. Ditargetkan selesai dan siap pakai pada akhir sprint.

Kendala yang saya hadapi sehingga pembuatan server ini memakan waktu cukup lama (1 minggu lebih) ialah mempelajari routing Express serta API Google drive.

Pada release nanti, kami akan melayani APK yang sudah siap install melalui server ini.

Selanjutnya, saya akan membahas alur kerja testing tim pengembang kami.

Testing with Jest for Node-based Apps

Kami menggunakan Jest sebagai framework sekaligus engine testing terotomatisasi pada proyek pengembagnan Ngangkot. Jest tergolong engine testing yang cukup unik karena dapat menggunakan Snapshot untuk melakukan testingnya.

Snapshot sendiri bekerja dengan membandingkan hasil generasi kode UI pada versi yang dites kali ini dengan kode UI pada versi yang dijadikan acuan snapshot testing (biasanya versi stable atau hasil commit sebelumnya). Hal ini sangat cocok dipakai untuk mengetes hasil commit yang banyak melakukan refactoring. Selain itu, Jest cukup mirip dengan framework dan engine testing pada umumnya, seperti Mocha + Chai dan Jasmine.

React-Native yang kita pakai sebagai platform development android untuk proyek Ngangkot ini memiliki code-code native yang tidak bisa ditest oleh Jest maupun framework dan engine testing berbasis javascript lainnya. Hal ini disebabkan code native tersebut langsung berhubungan dengan engine internal android, yang ditulis dalam bahasa Java. Hal ini mengharuskan fungsi serta library yang menggunakan native code tersebut harus di-mock. Mocking dalam Jest cukup sulit untuk dipelajari pada awalnya, karena saya belum pernah menggunakan framework testing populer baik pada javascript maupun bahasa lainnya. Namun setelah paham, ternyata mocking nya cukup intuitif asalkan kita paham inner working serta struktur dari library ataupun fungsi yang kita akan mock.

Pada gambar diatas, saya melakukan mocking untuk komponen react-native-maps. Untuk membuat komponen mock nya, saya mengembalikan komponen baru yang bernama mockmapview, yang memiliki fungsi-fungsi yang sama serta subkomponen yang sama pula(dan di-mock juga) agar benar-benar dapat menggantikan semua call ke fungsi react-native-maps.

Selanjutnya untuk melakukan testingnya sendiri, dapat dengan menggunakan fungsi test()

Pada potongan kode diatas ditunjukkan car amenggunakan describe() serta test(). Describe sendiri merupakan wrapper untuk kumpulan fungsi test yang mempunyai kesamaan. Saya memakainya untuk mengumpulkan test yang terkait satu komponen atau class yang sama.

dalam menjalankannya sendiri, dapat memanggil fungsi

npm test

Dengan sebelumnya sudah mendefinisikan script test pada package.json di root proyek yang ada.

Setelah itu, untuk mengotomatisasikannya pada gitlab CI, kita perlu memanggil fungsi tersebut pada file yaml CI kita serta pastikan juga sudah menyisipkan Jest pada devDependencies lalu menjalankan npm install agar jest sudah terinstall terlebih dulu.

Pada package.json:

lalu pada CI yaml:

– u digunakan untuk mengupdate snapshot yang dibuat.

Selanjutnya saya akan membahas salah satu library terpenting yang digunakan pada proyek ini : react-native dan react-native-maps

React-native

React-native merupakan framework pengembangan android yang dikembangkan dan digunakan oleh tim pengembang facebook. React-native memiliki beebrapa keunggulan diantaranya:

Hot reloading sehingga bisa melakukan penulisan code dan melihat hasilnya dengan luwes

library yang banyak

Berbasis Node.js

Selain keunggulan, terdapat juga kekurangannya yang kami rasakan setelah 3 sprint ini, diantaranya:

Masih baru, sehingga banyak fungsionalitas yang ada di native android library via android studio yang belum 100% stabil di react-native

paradigma komponen based yang cukup kompleks dan memerlukan waktu lebih untuk dipelajari bagi yang belum pernah mengenalnya.

Nah, selanjutnya saya akan membahas implementasi react-native-maps yang merupakan library penampil map geografis seperti pada googlemaps di react-native

React-native-maps

React-native-maps merupakan library yang dibuat oleh tim pengembang airbnb. Library ini memberikan fungsionalitas yang biasa ada pada map geografis seperti google map.

Berikut adalah tampilannya pada aplikasi kami:

[kiribang]

Sprint log #6 Last Sprint

Note: Karena keterbatasan waktu, saya mem-posting postingan ini dengan bahasa Indonesia.

Ok karena ini sprint log terakhir dan minggu akhir sprint, kali ini saya akan merangkum hal yang saya ingat sejak awal kelas PPL.

Pre-Sprint

Sebelum kelas PPL ada beberapa topik yang tersedia, namun karena kami membentuk kelompok saat menjelang masuk sehingga topik yang tersedia sudah diambil oleh kelompok lain. Topik / proyek kami adalah Angkot (moovit advanced version) dengan partner Bapak Setiyadi dari Fasilkom. Proyek ini singkatnya bertujuan untuk mempermudah pengemudi angkot untuk mencari penumpang.

Nah, dalam kuliah ini kita menggunakan metode agile scrum dalam proses pengerjaannya, karena scrum lebih fleksibel terhadap perubahan serta membutuhkan anggota yang lebih sedikit, dibanding prescriptive yang membutuhkan dokumentasi serta requirement yang lengkap serta membutuhkan anggota yang lebih banyak dan waktu pengerjaan yang lama, biasanya minimal 1 tahun.

Selain itu kita menggunakan scrum karena beberapa pengalaman-pengalaman sebelumnya yang menggunakan prescriptive, banyak proyek yang tidak selesai karena terlalu banyak di proses dokumentasi.

Kalau begitu apakah semua proyek dapat dikerjakan dengan scrum? Tidak karena ada beberapa proyek yang harus memiliki requirement yang sangat lengkap dan jelas. Contohnya seperti yang Bapak Eko pernah sampaikain dikelas yaitu, sistem pengontrol lampu lalu lintas. Kita tidak bisa mendeploy/mengimplementasikan sebagian, misalkan hanya lampu merahnya yang berfungsi atau semua lampu menyala namun tidak sinkron. Proyek seperti ini bahkan harus di tes dengan formal method sehingga semua requirement yang dibutuhkan dapat terimplementasikan.

Sementara proyek yang dapat dikerjakan dengan scrum adalah proyek-proyek yang memerlukan perubahan yang cepat. Misalkan e-commerce yang memerlukan penambahan fitur dengan cepat.

sumber: https://www.pinterest.com/pin/304063412321773119/

Berbicara tentang scrum, agile sendiri memilik beberapa jenis seperti extreme programming, kanban, dan agile itu sendiri. Extreme programming menekankan pada praktek pengerjaannya yaitu salah satunya, pair programming, sedangkan scrum lebih kepada metodologi pengembangan software, yang dalam prakteknya sebenarnya tidak terpaut pada suatu proses pengerjaan, sedangkan kanban yang mirip seperti scrum namun bisa digunakan untuk proyek non-IT misalkan pada pabrik mobil Toyota. Sehinnga dalam hal ini, kita bisa mempraktekan scrum namun melakukan pair programming dalam pengerjaannya misalkan coding, atau testing.

Selain agile sendiri memiliki nilai-nilai dan prinsip-prinsip yang dijunjung tinggi yaitu dalam agile manifesto, yang dirancang untuk pengembangan software yang lebih baik. Agile manifesto memiliki nilai-nilai yaitu:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Selain menggunakan scrum, kami juga menggunakan test-driven development yaitu membuat unit test dan test case-nya sebelum membuat implementasi. Hal ini saat bermanfaat karena kita dapat menjamin kualitas dari code yang kita kerjakan dan menghemat waktu. Unit test yang kita buat bisa juga menjadi kerangka/acuan dari code yang kita buat. Jika kita membuat code terlebih dahulu sebelum membuat test, maka akan sangat sulit untuk mendapatkan code coverage dengan maksimal.

sumber: http://www.seamgen.com/blog/quality-software-development/

Dalam scrum ini terdapat 3 sprint yang tiap sprint-nya dilaksanakan 1 bulan. Tiap 2 minggu sekali terdapat individual review dan diakhir sprint terdapat sprint retrospective dan sprint review.

Sprint 1

Dalam sprint satu ini kami menentukan user story yang akan kita kerjakan selama perkuliahan, kemudian setiap user story / backlog tersebut dipecah-pecah menjadi task-task dan juga dipecah sesuai role yaitu penumpang dan pengemudi dan menandai mana saja yang MVP. Kami juga menentukan chore-chore yang harus dilakukan. Kami melakukan simulasi ini dikelas ketika workshop dan bersama-sama diluar kelas menggunakan PivotalTracker

Lalu kami menentukan teknologi yang kami gunakan untuk pengembangan proyek kami. Awalnya kami menggunakan Android Studio karena proyek kami berupa mobile apps berbasis android, namun karena membutuhkan waktu yang lama untuk membuka, program tersebut dan launch project (download gradle, dependencies, dsb) sehingga kami menggunakan React Native sebagai alternative. Selain itu kami menggunakan React Native karena jika kita ingin membuat versi iOS dari aplikasi tersebut kita bisa langsung build tanpa melakukan porting karena dalam React Native kita bisa menggunakan source code yang sama untuk android atau iOS. Selain itu React Native merupakan Component-Based sehingga mengurangi jumlah class / module dibanding menggunakan Java dan diharapkan lebih reusable dalam menggunakan component tersebut dan diharapkan menghindari ‘pengulangan’ dan menulis DRY code (Don’t repeat yourself).

React Native yang berbasis javascript sendiri memiliki code convention, yaitu white space / indentasi sepanjang 4 spasi, variabel yang diawali dengan huruf kecil dan sebagainya. Javascript tidak peduli dengan jumlah spasi dalam kompilasi karena menggunakan bracket ‘{}‘ setiap block code tidak seperti python yang harus memerhatikan indentasi.

var input; // variable diawali dengan huruf kecil functionA(){     return 1 + 1; // indentasi 4 spasi / 1 tab }

Untuk lebih lanjut dapat dibaca di tautan ini.

Selain itu kami juga menyiapkan tools untuk testing untuk proyek kami. Kami menggunakan Jest yaitu package bawaan dari React Native untuk melakukan unit test dari fungsi-fungsi yang kami buat. Dengan melakukan perintah npm test pada command line didalam direktori kami bisa mendapatkan unit test mana yang gagal atau mendapatkan code coverage-nya.

Kami juga men-setting gitlab untuk melakukan testing dan building dengan Jest tersebut untuk melakukan testing dengan server gitlab.

Pada akhir sprint ini kami dapat mengerjakan semua backlog yang kita kerjakan yaitu, daftar rute angkot beserta detail dari rute tersebut.

Sprint 2

Pada sprint ini kami melakukan remake yaitu yang tadinya kita menggunakan webview sebagai komponen untuk me-render list dan map yang kita buat menjadi komponen dari React native. Selain itu juga kami juga menambahkan fitur baru yaitu fitur search untuk melakukan pencarian rute angkot.

Sprint 3

Dalam sprint ini kami menambahkan fitur baru yaitu ditampilkannya penumpang dalam map serta rute angkot yang bisa digunakan untuk mencapai tujuan. Untuk menampilkan penumpang dalam gps/map kami menggunakan websocket untuk meng-handle request antar client, yaitu user dan server yaitu heroku. Saya juga mempelajari bagaimana websocket bekerja dengan membuat aplikasi chat sederhana seperti yang sudah saya post pada sprint log sebelumnya.

Dalam sprint ini saya mengerjakan fitur untuk menampilkan rute yang bisa digunakan untuk mecapai tujuan. Saya menggunakan pendekatan euclidean distance untuk mencari titik terdekat antara titik lokasi penumpang dan suatu titik jalur.

Namun pendekatan ini memiliki banyak kekurangan misalkan bisa dibutuhkan lebih dari satu rute angkot untuk mencapai tujuan serta bisa saja ada jalur yang lebih baik dari jalur yang paling dekat dari penumpang tersebut.

Misalkan pada ilustrasi diatas dengan pendekatan euclidean, akan dipilih rute berwarna biru sebagai rute yang bisa digunakan namun pada kenyataanya rute kuning-lah yang melewati tujuan. Sebenarnya untuk mengatasi hal ini salah satunya bisa menggunakan A* namun karena keterbatasan waktu akhirnya pendekatan euclidean lah yang digunakan. Saya melalukan user story ini pada branch story-findNearestRoute

[kiribang]

sprint log #5

rI found out my problems with last week’s NativeBase List component not working as wished and turns out it’s because I put List component tag (what I referred as NgangkotList at react-native-menu branch) inside content tag, when it’s sufficient to use List component tag alone - whatever components inside a NativeBase Tab is already a content by itself. Oh, and the MenuTab is not supposed to be content too. it needs to be outside Content but inside Container.

after removing Content tag, I finally am able to make the list scrollable till the last entry and the tab headers stay fixed even after scrolling.

and yeah, I was kinda stuck on my own code because the testing and the running messed up out there. I tried uninstalling and reinstalling node_modules but it does not work. I tried loading map component but it does not load, when I installed what I need it borked up. and such and such. but at the end on the second sprint we sort merged it all into one branch.

for the third sprint my main task is to do a UI redesign and I started with the page which was already completed functionally, which is the routes list page

This is the mockup

There are two changes I intended:

Swapping the searchbar with NativeBase form (Item) element for consistency, adding a search icon for visual cue and revamping the List element. As a bonus addition, I changed the style into NativeBase built in material design theme. You can see it the most from the tab’s shape.

I tried coding the interface using NativeBase List element, which was supposed to look like the picture below, but I cannot make it functional as of now.

-Ghinaa

[kiribang]

Individual Review #5 - Agung

The week immediately preceding the sprint review was a rush. In that sprint I was tasked to draw angkot routes on map. After some initial difficulty on displaying the map, I was able to complete the task.

Next came the merging between features. It turns out that it wasn’t as simple as we had thought. The way our team did it, each team member is responsible in coding specific pages within the app. When we tried to connect those pages and pass variables among them, it didn’t work like it did in Java or any other languages/frameworks that uses MVC pattern. React, which uses Entity-Component-System architectural pattern has a different way to pass variables. Hours were spent in figuring this problem before we finally found the solution by following the instructions on this blog.

Since only two of our members had installed map library to our computers, we elected to use pair-programming in the merging process. It was a good choice as none of us has any noticable difference in coding skill and our partners drove our coding.

For the last week, I had done very little. Our main feature in this sprint requires websocket and server-side programming. We are currently debating on what language and platform should we use for that purpose. I installed node.js and firebase and did some test on my own personal heroku app. It turns out that node.js is a very pleasant framework to use so I’m going to advocate its usage for our server-side. 

[kiribang]

Sprintlog #5 - Drianka

In this first week of 3rd sprint and in the last week of previous sprint, our team did a number of significant sprint.My contributions is listed as follow:

Sprint 2 last week:

- Wrote and modified map implementation to show map on the apps

Sprint 3 first week:

- Rewrote test implementation because of the merging cause tests to fail (ongoing)

- Implement new function (halted)

For the map implementation, the code is written as map.js and uses both add on module of react-native-maps MapView and google webservice api for location searching. See the snapshot of the API call implementation below:

We also need to call hardware related function from the user’s android phone to get current location from the gps. we uses module native in react-native named navigator that could gives geolocation position of the device.

Since we also need to present the apps to the stakeholder/client in sprint review, we merge and combine all of our codes and scripts as a working apps. This leads to some problems function-wise and test-wise. For the function-wise one, after a bit of tinkering we could finish it before the review started last week. But for the tests, the problem became complex because of the new calls exchanged between many component that isn’t made before the merge.

currently the test have passed for some of the script, but for some other are yet to be fixed.

This too obviously affect the coverage

hopefully we could fix the test before the weekend so we could focus on other impending task for our last sprint

[kiribang]

Sprint log #5 - Irfan

In this sprint our apps require network request from clients like the position of passenger, show closest drivers from passenger, etc. So to handle this, we use either php websocket called Ratchet or Node js.

Ratchet

Before we deploy it to our heroku server, I decided to learn and try it out locally. It require php library which I get from XAMPP and Composer a package manager for php which is quite similiar with npm for node package.

First I installed composer in my computer and set it’s php directory to XAMPP’s php directory. Then to make sure it installed correctly using cmd to check it version with:

composer -V

Output:

Composer version 1.4.1 2017-03-10 09:29:45

php -v

Output:

PHP 5.6.14 (cli) (built: Sep 30 2015 14:32:12) Copyright (c) 1997-2015 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies

Then Install the Rachet using this command:

php ~/composer.phar require cboden/ratchet

Then I followed the tutorial from Ratchet’s site to create a simple chat application using telnet client. First I create a php file called Chat.php and put it inside src/MyApp folder. It holds the logic for our chat. Then here what it looks like:

<?php namespace MyApp; use Ratchet\MessageComponentInterface; use Ratchet\ConnectionInterface; class Chat implements MessageComponentInterface {    protected $clients;    public function __construct() {        $this->clients = new \SplObjectStorage;    }    public function onOpen(ConnectionInterface $conn) {        // Store the new connection to send messages to later        $this->clients->attach($conn);        echo "New connection! ({$conn->resourceId})\n";    }    public function onMessage(ConnectionInterface $from, $msg) {        $numRecv = count($this->clients) - 1;        echo sprintf('Connection %d sending message "%s" to %d other connection%s' . "\n"            , $from->resourceId, $msg, $numRecv, $numRecv == 1 ? '' : 's');        foreach ($this->clients as $client) {            if ($from !== $client) {                // The sender is not the receiver, send to each client connected                $client->send($msg);            }        }    }    public function onClose(ConnectionInterface $conn) {        // The connection is closed, remove it, as we can no longer send it messages        $this->clients->detach($conn);        echo "Connection {$conn->resourceId} has disconnected\n";    }    public function onError(ConnectionInterface $conn, \Exception $e) {        echo "An error has occurred: {$e->getMessage()}\n";        $conn->close();    } }

as you can see it quite long but here is some explanation for each methods:

onOpen

Called when a new client has Connected. In this case we print a message to console

onMessage

Called when a message is received by a Connection. In this case we send the chat message from a client to all other clients.

onClose

Called when a Connection is closed

onError

Called when an error occurs on a Connection

Then I create chat-server.php and store it to bin folder. This file will instantiate the server.

<?php use Ratchet\Server\IoServer; use MyApp\Chat;    require dirname(__DIR__) . '/vendor/autoload.php';    $server = IoServer::factory(        new Chat(),        8080    );    $server->run();

As you can see, It instantiate the chat class which hold the logic and create connection 8080 port.

Then run this to synchronize our application

composer dump-autoload

Then run this command to try it out

php bin/chat-server.php

Then I run another 2 cmd and run this command:

telnet localhost 8080

And our simple chat should looks like this:

Node Js

Another way to handle the interaction between client and server is using node js. So to learn how to use it. I create another ‘chat’ program which is from this youtube tutorial.

First I crate index.html which is contain the logic of our application and simple textfield with button and prompt to insert your name and renderer to render the message from the client.

I also create index.js which contain the logic to handle the request from client to server, in this case we use port 5001.

var server = require('ws').Server; var s = new server({port: 5001});

var name;

s.on('connection', function(ws){ ws.on('message', function(message){ message = JSON.parse(message); if(message.type == "name"){ ws.personName = message.data; return; } //console.log("Received: " + message); s.clients.forEach(function e (client){ if(client != ws) client.send(JSON.stringify({ name: ws.personName, data: message.data })); }); }); ws.on('close', function(){ console.log("I lost a client"); }); });

As you can see the method is kinda similar from Ratchet.  Node js’ on('message' ) is equal onOpen in Ratchet which is called when a client is connected. Node js’ on('close') also equal with Ratchet’s onClose which is executed when a client is disconnected.

With XAMPP running the apache and this command with cmd In the project directory, we should be able to run our chat application.

node index.js

So, our simple chat application with node js should looks like:

[kiribang]

Sprint log #5 -kabul

Ora specific document root directory On the last sprint our group start by configure the server thats going to facilitate the communication between clients. The clients in our case are the angkot’s passenger and driver. 

The passenger will periodically send an info of its’ location, current speed, and the route it would take, while the driver wil send the route that the angkot is taking the server. The server then will match the passenger and angkot that is currently on the same route and send info of the passenger’s location to the driver. This allow the driver to know how many passenger using the app is taking the route and obtain information on where to pick up the passenger along the route. After that if the current speed of the passenger is going above the treshold of walking speed, the passenger then considered to be picked up by the angkot and stop sending data to the server. Personally, I am in charge of the user story on checking whether the passenger already taken the angkot or not using the method mentioned above.

We choose php as the framework of the server since most of our team already familiar with it in order to speed up development. For testing and development PHP has a direct module interface called SAPI (Server API), which provides an interface between PHP and the web server. As of PHP 5.4.0, the CLI SAPI provides a built-in web server. In order to use it, you just need to go to the current working directory where PHP was started and start your server there. For example :

$ cd ~/public_html $ php -S localhost:8000

If it is working correctly, then the terminal will show something like this

PHP 5.4.0 Development Server started at Tue May 02 09:34:56 2017 Listening on localhost:8000 Document root is /home/me/public_html Press Ctrl-C to quit

It will then listen to URI requests for http://localhost:8000/ on the root directory. In my case, it will give an output like this

PHP 5.4.0 Development Server started at Thu Jul 21 10:43:28 2011 Listening on localhost:8000 Document root is /home/me/public_html Press Ctrl-C to quit. [Tue May 02 09:34:48 2017] ::1:39144 GET /favicon.ico - Request read [Tue May 02 09:34:50 2017] ::1:39146 GET / - Request read [Tue May 02 09:34:50 2017] ::1:39147 GET /favicon.ico - Request read [Tue May 02 09:34:52 2017] ::1:39148 GET /myscript.html - Request read [Tue May 02 09:34:52 2017] ::1:39149 GET /favicon.ico - Request read

You can also start the server with a specific document root directory with

$ php -S localhost:8000 -t yourDirectory/

Or even directly run a php script along it with

$ php -S localhost:8000 yourScript.php

Since our heroku server is already running php, hopefully we can further develop and test our app more swiftly.

[kiribang]

sprint log #4

1. Restoring files and reimplementing test script. Time allocation: around 4 hours.

Due to me accidentally permanent-deleting the project folder in my laptop, I have to restore my files from GitLab. And the first thing I did is to readjust the testing code to make sure it will work with components from NativeBase (nativebase.io, native-base in npm), another cross-platform UI component library, which provides not only tab menu interface, but also other UI components. However, npm test does not work well at the first time.

This can be fixed with installing jest in npm with the command npm install jest-cli --save-dev

And when I am running the testing script, it failed and not because I did not run it on the expected code, but because the test suite cannot run. The error code is:

 ● Test suite failed to run

    C:\Users\aysdf\PPLC2\NgangkotMenuTab\node_modules\@shoutem\theme\index.js:1

  ({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,global,jest){import connectStyle from './src/connectStyle';

                                                                                            ^^^^^^

  SyntaxError: Unexpected token import

      at transformAndBuildScript (node_modules\jest-runtime\build\transform.js:320:12)

    at Object.<anonymous> (node_modules\native-base\dist\src\index.js:1:1116)

    at Object.<anonymous> (__tests__\index.android.js:3:17)

 Apparently, this is caused by using something with Node modules, which is in default blacklisted from being transformed with babel if they don’t pre-compile their source codes (I suspect NativeBase did this). However, it could be fixed by editing the package.json configuration file. Find the “jest” JSON data, and add this line:

"transformIgnorePatterns": [

 "node_modules/(your node module folder)/"

]

inside it.

 Now, the test result is:

 Now that’s an expected result. Failing the test because it ran but it does not have the components from the previous module (react-native-tab-view) imported. Since I am using another module that kind of works the same, I don’t think I’ll need that one again.

 2. Debugging files post-Git conflict. Time allocation: around 4 hours.

I committed the test script but there was a Git conflict. I was going to jump to coding (even when the test script failed to run). There has been a stack of error waiting for me. The conflict had corrupted my already-ruined files—I changed folder name midway and React Native did not adapt to it automatically. I have to adjust file and package names in a lot of files.

 3. Implementation. Time allocation: 6 hours

The coding to make and maintain layout is made way simpler by NativeBase and it provided complete, cross-platform UI components, but when I go further with it, I found problems on implementation with NativeBase.

First, the tab position is not fixed by default.

Second, I tried making a dummy component including a NativeBase List, NgangkotList. I entered the name of angkot routes displayed in Sprint 1’s Heroku WebView as its content, however it only loaded things up until D11.

4. Test running. 1 hour

I readjusted test scripts to display dummy elements and added yaml file so that test will run at the pipeline

-Ghinaa

[kiribang]

Sprint Log #4 Drianka

This week I did the following things:

1- Look for regex for catching coverage output in gitlab

2- Using MapView for displaying map

3- testing fetching http post with react-native

4-Jest testing for current feature

5- Set up native base as UI package in react-native

point 1 ,2 and 5 are already done. But point 3 are still buggy so I need more time to understand it. Point 5 are in progress, I still studying how to test using snapshot and shallow rendering. Current build is still a mess so I cannot post screenshot here. I’ll update this log in the end of the week after the feature is ready to post

[kiribang]

Sprint #4 2017-04-19

Hi, I will show you what I have do so far from latest sprint review. 

Store routes data to the database

I put the all the data to the heroku postgres databases and here what’s looks like:

With the pgAdmin4 I put all the data. Each row contain id, name, source, destination, logo, and it’s geojson. I also constraint all of the column to make sure it’s not empty/null.

Retrieve the database and convert it to json

Using php, I convert the database query into json and I put that php function to heroku. Because all the data contain almost 2 Mb and it takes longer to load, I divided the php function into two parts. If we don’t specified the routes name, we get all the data except the json. If we specified the name, get the json of that specified name.

<Without specified name>

<With name>

Create Searchbar

With react-native I create the search button and create a function to fetch the json and show it as the list. It needs more styling because obviously it’s not looks good. But the point is, it successfully retrieve the data from the database.

Also I push this progress to gitlab and It pass the tests.

[kiribang]

Individual Review #4 Agung

In this part of the sprint, I was assigned the task of displaying angkot route on the map. I made a test to see if the map is displayed correctly :

To accomplish the task, I used native-react-maps library by airbnb.

I also fetched a token from Google API and installed the Google Play service sdk. It turns out, however, that I don’t need to interact with Google API right now because I already have the JSON needed to draw the route and native-react has its own Polyline drawer.

At first, the mapview displays a blank canvas. Searching for the solution for this problem leads me to find that the fault lays on the buggy new version of the airbnb library that had been updated just ten days ago, as of this writing. I asked airbnb’s developer on github on how to resolve this and they suggested

After passing the problem of blank canvas for days, it turns out to be a smooth sailing from there. Drawing route on map is just overlaying a set of coordinates inside the mapview, so it was no problem getting that done.

A problem arose when I got the bright idea of updating all my sdks and switching emulators. After doing so, it was back to the blank map. Some problem with the dependency, my console log says. 

Infuriating as it is, once I get past the problemI will have completed this task. Afterwards, I’m going to find out if I can get some real-time capabilities on a map-marker.

19 April 2017

[kiribang]

Sprint  log #4 [Kabul]

This week we’ve been reimplementing all the user stories that we have done to react native. 

The task I’m helping with is to show map and showing route list. For each user stories, new branch is made from the latest develop branch. A commit with RED tag is commited on the addition of unit testing. After I write the code and it pass the test, another commit is made with the GREEN tag.

On testing, I encounter a problem where jest did not properly mock the component correctly. A workaround is used to mock the component by rendering out some of its row to test it.

after every user stories are done, a merge and integration could be done to make it one working software

[kiribang]

Sprint log #3

For the current sprint, I am taking the job of displaying angkot routes on map. I managed to display the map when it was written in index.android.js, but I couldn’t get it to work when I put the code inside a component to be exported. The error is looks like something in this vein :

I tried moving the component files around and it still couldn’t work. When I asked other team members on this, they said they didn’t encounter such an issue. I need to ask them on our next meeting. On my to-do list is figuring out how this component import-export system works and reading the input from GeoJson to render it on the map.

-S. Agung

[kiribang]

SprintLog#3 - 4 April 2017 [Drianka]

So the time has come for me to move on from setting up the environment (mainly the gitlab CI yaml script) to actual implementation of feature in react native. I picked “Sebagai penumpang, saya ingin dapat mencari lokasi tujuan saya di peta agar saya dapat dengan mudah memillih lokasi tujuan” user story on current backlog for sprint 2. Honestly I’ve yet to do anything to finish the task because of how hectic past week was (midterm test week happened).

What I gonna do in this week are setting up branch and test suite for my task and creating BASH script to ease regex catching for code coverage display on gitlab.

Oh, I did move tasks from current backlog item on pivotaltracker to gitlab issues.

Have to set assignee fast to reduce miscommunication now. I also had requested to merge develop branch to master to our beloved scrum master.

Hopefully we could finish this sprint feature fast, so that other feature which we didn’t take on our initial sprint planning could be worked on too.

-Drianka