Narbase Technologieshttps://narbase.com
Sun, 14 Oct 2018 07:19:52 +0000en-UShourly1https://wordpress.org/?v=4.9.4https://narbase.com/wp-content/uploads/2018/03/cropped-white-32x32.pngNarbase Technologieshttps://narbase.com
3232Clean Codehttps://narbase.com/2018/10/14/clean-code/
https://narbase.com/2018/10/14/clean-code/#respondSun, 14 Oct 2018 07:19:13 +0000https://narbase.com/?p=681It’s an amazing feeling when you see your app is coming to life and more features and decorations are added to it every day to make it better, and we are very close to the first fully functional version of the app.

Last week Islam and Hind decided to get rid of the RecyclerView that we were using in the app and extract all code from it to normal classes, and sure that what we did. That aroused a couple of problems that the RecyclerView has solved out of the box but after a pair programming session with Islam we solved many of these problems except for one that I had to solve it on my own, I couldn’t figure out the solution yet, but I am very confident that I am gonna find it soon.

A couple of weeks ago Islam told me about a book called “Clean Code” by Robert C. Martin, he told me to check it out because it will teach me lots of things. If you remember I mentioned clean code in a previous post. I didn’t have any chance to check the book until this weekend. So this week post will be a small peek into the book introduction and the first chapter that named “Clean Code”.

The book introduction starts with the comic above, and besides it’s very funny and accurate I think we all know that we need to write a good and clean code and keep a low rate of “WTFs/minute” for our code reviewers :].

The author mentioned many reasons for why writing bad code is a bad thing and what the cost of a messy code. He mentioned a story of a company in the late 80s that had a very popular app, lots of professionals used it, but after a couple of releases, users start abandoning their app because the app became sucks. An old employee of the company met the author after many years and told him that they rushed to put the product to the market, and their code was a mess and they continue developing and add more features in that mess to the minute they couldn’t manage that mess anymore. And the company brought down because of that bad code.

The author said that we probably come across bad code and be impeded by it, and we probably wrote a bad code ourselves trying going fast to meet the deadline and not to make our boss angry when you took times to clean up your code. So you say to yourself “it’s working now why we bother ourselves trying to clean it up the code now and let’s do that later”.

I learned there is a law called LeBlanc’s law, and no it’s not Matt LeBlanc, it’s another LeBlanc. The law says “Later equal never”. I personally knew this law is true, lots of times I had to modify some parts of the code or rename some variables or functions and deal with some issues, and I say to myself “I will do that later”, and as LeBlanc’s law suggested I never did, and because there are so much new code to write and more features to add, the “I will do that later” list will increase and you will miss track after a while and it will turn up to a huge mess. The same story with cleaning your code.

The author mentioned that the messy code can cost you a lot, if you start very fast at the beginning of the project you will force to slow down along the way and your productivity level will decrease and it may actually reach zero. So taking the necessary time to keep your code clean is not just a matter of cost-effectiveness, it’s a matter of, and I quote the author words “it’s a matter of professional survival”.

The next part I had to quote because he describes it way better than I will ever do “Have you ever waded through a mess so grave that it took weeks to do what should have taken hours? Have you seen what should have been a one-line change, made instead in hundreds of different modules? These symptoms are all too common. Why does this happen to code? Why does good code rot so quickly into bad code?”

The author said that new developers(with experience less than a few years) know bad code will slow them down but they do it anyway to meet the deadline , but true professionals know that with a messy code you will not make the deadline, and you have to keep your code as clean as possible all the times, because this is the only way to make the deadline.

So What is the Clean Code?

The author asked many of well-known and deeply experienced programmer about what they think about clean code, you may recognize some of them. I will quote two of these programmers.

Bjarne Stroustrup, inventor of C++ and author of The C++ Programming Language said “I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.”

Michael Feathers, author of Working Effectively with Legacy Code said “I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you’re led back to where you are, sitting in appreciation of the code someone left for you—code left by someone who cares deeply about the craft.”

I think now you want to know what the author himself thinks clean code is?. Here I quote his words “What about me (Uncle Bob)? What do I think clean code is? This book will tell you, in hideous detail, what I and my compatriots think about clean code.”

So that’s mean we need to continue reading the book, till now for me this book is very promising and I will keep you updated while I go through different chapters. Now I will leave you with this question “Do you now appreciate the value of writing clean code?”. Share with us your thoughts in comments, but for now, that’s it for this week.

Till next week.

]]>https://narbase.com/2018/10/14/clean-code/feed/0Postgres Spork! or Why we switched to PostgreSQL After 2 weeks with MongoDBhttps://narbase.com/2018/10/07/postgres-spork-or-why-we-switched-to-postgresql-after-2-weeks-with-mongodb/
https://narbase.com/2018/10/07/postgres-spork-or-why-we-switched-to-postgresql-after-2-weeks-with-mongodb/#respondSun, 07 Oct 2018 06:52:08 +0000https://narbase.com/?p=667Ok Ok. I promise this is the last time I will write hailing another database solution as the one that solves all my issues. At least, I hope so.

If you have been following my posts, you may remember that my application stores some data that is very dynamic (i.e. different subtypes that will probably change a lot in the future). I didn’t like creating a lot of relational tables whenever I add a new type. Managing these tables wasn’t a lot of joy either and most database reads in my use cases required tens of joins. All of this made relational databases seem less than ideal. At this point I was introduced to MongoDB and I loved it. MongodB sidesteps this issue completely by embedding all these different types of entities within their parent entity. Suddenly I didn’t have to deal with multiple tables or even modify the database when adding a new type; Reads for my use cases now use a table or two instead of running tens of joins; the world is beautiful! Or is it?

Mongo essentially sacrifices referential integrity between tables. My team leader reluctantly accepted this because he values “developers happiness “, as he puts it, because he realized that the embedding model of Mongo makes our lives considerably easier. It seems he wasn’t that happy about the compromise though, so he dug around and brought me a spork, PostgreSQL.

Postgres is a very popular ORDBMS that efficiently combines the integrity of the relational models with the flexibility and performance of the Object models at the same time. Postgres JsonB data type, which is quite similar to Mongo’s bson representation that stores all their data, has shocked the industry by outperforming Mongo a few years ago. It seems Mongo has improved again surpassing Postgres, but it still remains incredible. A good explanation of this is provided in this article I recommend reading It is also where the title of this post comes from (spork).

So this settles it. The complex objects are stored on JsonB columns while the rest of the database is relational with integrity guarantees. I am quite happy with this arrangement and it seems like the perfect solution but I may have said such words about Mongo before so what do I know. I will keep you posted if any changes happen.

]]>https://narbase.com/2018/10/07/postgres-spork-or-why-we-switched-to-postgresql-after-2-weeks-with-mongodb/feed/0Android without XML: Anko Layouthttps://narbase.com/2018/10/07/android-without-xml-anko-layout/
https://narbase.com/2018/10/07/android-without-xml-anko-layout/#respondSun, 07 Oct 2018 05:11:32 +0000https://narbase.com/?p=635Tick Tok the clock is ticking and the deadline for the first demo of the app that Ayman and I were working on for the past month is coming very quickly, but we almost got there.
Last week I continued working on taking a picture using image cropping library and upload it to the server. Sending files -including images- to the server is done using Multipart POST request, not a normal POST request, there are more lines of codes needed to be written to handle the Multipart request and Retrofit made it very easy to do that. Future Studio channel on Youtube and their website have a good tutorial on How to Upload Files to the Server, and they also have very good tutorials on Retrofit and related topics.

Also, I worked on the UI for the app. Hind sent me the app design and my mission was to apply that design on the app, which was very amusing to see the user interface turning from ugly and unpleasant for the eye to a simple and nice user interface, with nice colors and views positioning that the user can act with them with ease. I did a basic design while I was working on the app but this design was way better than mine, which reminds me to work on my designing skills.

I also worked with the creation of the views programmatically at the code depending on the data coming from the server. Let’s take an example to demonstrate why I needed to create views in the code and not simply put them it in the XML as usual. If the app has EditText views but the numbers of EditText views will be defined by the data coming from the server. So -as far as I know- you can’t do that in XML because you don’t know how much EditText you gonna need to create, so you will need to create those EditText views in the code when these data arrive from the server.

There is the normal way of creating views in the code, or you can simply do like I did, I create these views in code Anko Layout style.

This week’s post will be another tutorial, and it will be on how to use Anko Layout. In this tutorial we will create a very simple app that doesn’t do anything interesting, it will just show an image with a text in front of it, so that’s mean we will use a Relative Layout. It will look something like the following:

We will create this without writing a single line of XML and we don’t even need the activity_main.xml file.

Like the previous tutorial, all codes for this tutorial were written using Kotlin, I am using Android Studio 3.0.1. Now create a new project in Android Studio and name it Anko Layout ,and make sure to check to include kotlin support and choose an empty activity.

As always, you have to add the dependency for the Anko Layout in gradle, as follows: (Add in build.gradle(Module:app) file)

In build.gradle(Project:AnkoLayout), add the anko version, in the time of writing this tutorial the anko version was:

ext.anko_version = '0.10.7'

Now is time to sync your project.

The Project Structure

The project structure will be as follows:

As we can see we don’t have any XML file.

We can create all the layouts in the MainActivity but it’s a good practice to separate the UI classes from Activity classes, and here in Narbase we always apply good practices. So I created a new class named MainActivityUI.kt.

Customization of any components it’s the work of lparms at the end as you can see in the code above, between its parentheses you can set the width and height and in the brackets after it, you can specify the layout alignment, margins and so on (layout related). In the brackets after the view name, you can set its text, text size, scale type and other attributes related to the view itself.

That’s is for this week, I hope you benefit from this tutorial and if you have any feedback, comments or any questions just let us know in the comment section.

The credit for the photo that had been used in this tutorial from raywenderlich.com. You can also check this tutorial if you want another example on Anko Layout.

Till next week.

]]>https://narbase.com/2018/10/07/android-without-xml-anko-layout/feed/0Attack on RecyclerViewhttps://narbase.com/2018/10/07/attack-on-recyclerview/
https://narbase.com/2018/10/07/attack-on-recyclerview/#respondSun, 07 Oct 2018 04:53:09 +0000https://narbase.com/?p=590Last week my productivity level had increased and I was able to finish more tasks than the previous weeks. I became more familiar with the concepts and things that I am working on, my ability to find answers and solutions for my questions and problems became better, it’s all about how you ask your question.
Last week I finally solved one of the problems I faced for the past two weeks which is how to display multiple view types in multiple view holders within the same RecyclerView adapter which made working with other tasks much easier. Also, I used Anko library to create views in the code much faster than the conventional way, you can check their GitHub page for more information. Also, I start working with another library to deal with images, it helps you to take pictures and crop them as you want. The library does very much anything for you, all you have to do in your code is to tell the library you want to take a picture then it will open the camera or gallery or any other application of your choice then start a new activity for cropping your picture, then return your cropped picture to your activity. You don’t even need to create a new activity for cropping the picture the library will created for you, you just need to add the activity to your manifest file. For more information about this library, you can check their GitHub page. I may do a tutorial on how to use this library in the future.
Islam told me that one of the reasons that I am writing these posts because it is a way of knowledge sharing and giving back to the open source / free knowledge community. I am a big supporter of free knowledge, I personally benefit a lot from videos, tutorials, and articles that people share online for free just for the sake of sharing knowledge. So this post will be a tutorial on how to use multiple view holder within a single adapter. I am not saying this is the best way to do it, I will just show you how I solved it and what worked for me.

I talked about the RecyclerView in a previous post. You can check it out before continuing in this tutorial. This tutorial was inspired by this tutorial. Also, I am a fan of the anime “Attack on Titans”, so I will use some of the anime characters in the tutorial. The source of photos and information from this website.

All codes for this tutorial were written using Kotlin, I am using Android Studio 3.0.1. I will assume that you know how to start a new project and I will also assume that you checked the auto-import option in the setting.

First of all, you have to add the dependency for the RecyclerView in gradle, at the time of writing this tutorial the dependency

implementation 'com.android.support:recyclerview-v7:27.1.1'

Add this line to gradle then sync the project. Now you are ready to use the RecyclerView.

The project structure

In this tutorial, we will implement two view types(quote, character info) that will be inflated by two different layouts, each one of them has its own implementation (view holder) in the recycler view adapter.

Here is a screenshot of the project structure for this tutorial

Code

Lets start with layout (res/layout), but first add these lines to the string.xml file located add res/values

It has couple of texts and an image to displayed later each one in its related view holder.

For the MainActivity.kt two functions are added. The first function is for creating an array list and fill it with required data to be send later to the recycler view adapter. The second function is for just setup the layout manager for the recycler view and set its adapter. In the onCreate function in the MainActivity.kt these two function are called.

I hope you enjoyed and benefit from this tutorial. If you have any feedback or questions please leave a comment.

So that’s it for this week.

Till next week

]]>https://narbase.com/2018/10/07/attack-on-recyclerview/feed/0From RDBMS to NoSQL – 1 week with MongoDBhttps://narbase.com/2018/09/30/from-rdbms-to-nosql-1-week-with-mongodb/
https://narbase.com/2018/09/30/from-rdbms-to-nosql-1-week-with-mongodb/#respondSun, 30 Sep 2018 07:01:32 +0000https://narbase.com/?p=607I have talked about how I felt restricted rather than served by the relational model in my current project. The Scrum master suggested trying MongoDB since it seems suitable for the task at hand, and so I did. I feel it was a very interesting experience.

MongoDB is a document-based database that is one of the most popular NoSQL DBMS available. The basic premise is that you store your data in “documents” which are essentially a more sophisticated JSON representation of your data entities. The documents are stored in “collections” and they, usually, schema-less. That is to say, you don’t have to shape your data in strict ways to store and retrieve them. This delays and reduces the effort of designing a database as you would have to do in a relational model. For example, let us say you have a lot of similar objects that you want to store and that you retrieve in similar use cases. In an RDBMS, you will likely have to structure them with a base table that has a type field and a lot of secondary tables that implement these different types and refers to the base table. What about Mongo? well, you can simply dump all of these “different” documents in the same collection and you will get the fields you need for every type! When you add a new type or modify an existing one you might not need to do anything database-wise. Awesome! right? But this isn’t even the best part!

The best part, for me at least, is the arbitrary complexity of the documents! A document can have sub-documents that have their own sub-documents ad-infinitum! MongoDB recommends embedding data that belong together as much as possible. In my case, I have templates that have various entries which vary a lot in attributes and can have entries of their own. This was annoying to implement in an RDBMS since I had to create various tables and I had to implement a certain order of operations when trying to save a new template so that I can accommodate all the foreign keys and the like. In Mongo, I just dump the whole template in a collection and that’s it. It also makes a lot of sense, since these entries really belong to the template and if I want to delete the template I will delete them too. Now that they are literally a part of the template “document”, deleting the document deletes them too without needing to run a lot of queries on a lot of tables while paying attention to foreign keys restrictions. Obviously, there are times when embedding is inappropriate and you need to refer to other documents via referencing.

This leads us to the parts where Mongo seems less than ideal. The schema-free nature and focus on creating rich flexible documents came at the expense of inter-document data integrity. It seems there is no actual alternative for foreign-key restrictions in MongoDB and the application will have to maintain data integrity on its own. The same issue pops to some extent for the data integrity of collections too. The balance between restricting the fields of documents that can be accepted in the collection and providing freedom for different future changes seems to be a compromise the designer has to make.

All in all, Mongo is a rather exciting experience. I think it suits my project a lot since it has a lot of complex nested entities that have sole ownership of their members and the project itself seems in flux with many changes expected to be added in the future. It seems indeed possible to structure an RDBMS well enough to adapt to the future changes, but Mongo makes this task a breeze. On the other hand, if you have fixed well-defined structures without a lot of them belonging solely to certain entities, or if you have high needs for integrity on the database level, then a classic RDBMS is probably your best choice.

]]>https://narbase.com/2018/09/30/from-rdbms-to-nosql-1-week-with-mongodb/feed/0Good Practiceshttps://narbase.com/2018/09/23/good-practices/
https://narbase.com/2018/09/23/good-practices/#commentsSun, 23 Sep 2018 05:29:23 +0000https://narbase.com/?p=558Last week we did our first sprint review meeting, basically is a discussion about the tasks of the previous week, which tasks were finished and which tasks were not and why, and if their any problems facing any member of the team and how to deal with those problems, and also show the business owner the progress in the tasks and the finished features. For my tasks, I was not able to finish even half of them because all of the concepts were fairly new to me, but in the sprint planning meeting which held immediately after the review meeting my tasks from last sprint were simply transferred to this sprint and one more task was added to work on it also this sprint.
Last week I worked on fetching some data from the server using DTOs and network caller and display that info on a recycler view and create another POST request and its associated function to fetch more data from the server. The functionality of the network caller was already written I just reuse it in my view model, and yes I needed to create a view model to handle the calling and data fetching, and also I defined in the view model some LiveData objects and use an observers on my fragment to notify the required function whenever these data changes to acts upon that. I will talk about the view model and LiveData in another post, but in this post, I will focus on some points Islam discussed with me last week.
Islam regularly reviews my code that I regularly push to the project repository in GitLab. On the Thursday morning I found an email from Islam with some valuable and useful advices and good practices, and I would like to share a few of them with you:

Islam told me that I have to commit only the source code not the output and generated files, because I was committing every file in the project and that made the remote repository in GitLab became very large, and according to Islam ideally it should be a few MBs. So I needed to delete all the build files and output files from only the remote Git repository to do that I found a good answer in StackOverflow, as follows:
For a single file:git rm --cached mylogfile.log
For a single directory:git rm --cached -r mydirectory
And you typed that in the terminal of the Android Studio. After that, I needed to add a .gitignore file in my local repository and added files that I don’t need to commit, so Git will ignore these files whenever I do commit in my local repository.

In my code, I have to abide by Kotlin formatting. In Android Studio you can simply do that by using the shortcut Ctl+Alt+L to reformat your code. I am using Linux Mint and this shortcut lock the screen by default, so I had to change that in the setting first before I was able to use that shortcut in Android Studio. check this answer in StackOverflow for more and the shortcut for other OS.

In my code, I commented some parts of the code I didn’t need, but I want to keep them just in case, and my code looks kind of messy and not clean at all. So Islam told me just to delete those lines and whenever I need them I can always get them back from Git.

Islam told me to avoid comments that describe what I am doing, instead, I have to extract the code and use the function name to describe what I am doing. He told me that descriptive comments are bad comments. Let me show you an example to demonstrate to you what he meant by that (the example in Kotlin):

That comment is a descriptive comment and better way to do that is by separating the functionality of calculating the average in a separate function and let the name of that function to describe its functionality

That’s better and cleaner. Nothing better than a code that can describe itself.

That’s it for this week.

Till next week.

]]>https://narbase.com/2018/09/23/good-practices/feed/2First Sprinthttps://narbase.com/2018/09/23/first-sprint/
https://narbase.com/2018/09/23/first-sprint/#respondSun, 23 Sep 2018 05:20:45 +0000https://narbase.com/?p=527It’s already halfway my internship, times flies huh! But till now I learned a lot and practiced a lot.
Last week I talked about Scrum and the weekly Sprint, so last Sunday morning was our first sprint meeting, but wait! I forgot to tell you about those meeting right?. Let’s first do some recap, Scrum simply a framework that helps to manage Software projects which contains three of three. Three roles which are the product owner, the scrum master and the team. Three documents which are the product backlog, the sprint backlog, and the burndown backlog. Three meeting which are the sprint planning where the product owner, scrum master and the team meet to discuss the user stories and estimate the relative sizes, the daily scrum is a brief (5 – 10 minutes) stand-up meeting – which we are doing it literally standing – where the team – and sometimes the scrum master – discuses what they have completed since the previous meeting, what they’re working on and if anyone need help with something, the last meeting is the sprint review and retrospective meeting which occurs at the end of the sprint, this when the team demonstrate the completed work to the product owner and then the team discuss what type of improvement they can do and implement in the next sprint.
In our sprint planning meeting we discussed the backlog we worked on it last week and defined which user stories we will work on it this sprint and size the time needed for each one, we even have a board to keep track of what we are doing. My tasks included working with bottom navigation, create multiple activities and fragments.
According to Material Design website “Bottom navigation bars display three to five destinations at the bottom of a screen. Each destination is represented by an icon and an optional text label. When a bottom navigation icon is tapped, the user is taken to the top-level navigation destination associated with that icon.”. If you open your Instagram app, the bar you will see at the bottom is an example of the bottom navigation bar. There are many libraries to implement the bottom navigation bar, even google provide a support library, but for our purposes, we decided to use an open source library called ahbottomnavigation , the library github page provide a good example on how to use the library, you can check it if you want.
I spent a lot of times trying to figure out how to use this library but eventually, I designed a simple bottom navigation bar with three tabs. After that I needed to create three fragments and link each fragment with its corresponded tab, so when I click on a tab its correspond fragment should appear and after lots of time I linked them and that was a small victory moment for me.
Now let me give you a brief explanation of fragments. According to the Android Developers website “A Fragment represents a behavior or a portion of user interface in a FragmentActivity. You can combine multiple fragments in a single activity to build a multi-pane UI and reuse a fragment in multiple activities. You can think of a fragment as a modular section of an activity, which has its own lifecycle, receives its own input events, and which you can add or remove while the activity is running (sort of like a “sub activity” that you can reuse in different activities).” So as it appears using a fragment gives you more flexibility than using an activity, you can use a single activity for your whole app and the rest of your app functionality you can accomplish using fragments. Using fragments provides you with modularity where you can divide complex activity code across fragments for better organization and maintenance, reusability where you can share fragments across multiple activities and many other benefits of using fragments. To keep in mind you always need at least one activity to act as a host for your fragment and the activity lifecycle affected directly the fragment lifecycle, as an example if your activity is paused or destroyed so all the fragments, but when the activity is in resumed lifecycle (activity is running), you can manipulate each fragment independently. For more information about the fragment, you can check the documentation in the Android Developer website and this awesome tutorial.
My other task was to create a RecyclerView in the first fragment to display some data, these data come from the server which Ayman had been working on it. Ayman creates the DTOs and gave it to me to implement it in my code so I can be able to communicate and fetch data from the server. DTO stands for “Data Transfer Object” which is an object that carries data between process. Since each call to any remote interface – such as the server – is expensive, response to each call should bring as much data as possible. So for a particular task that needs data and requires multiple requests, these data can be combined and encapsulate in a DTO so that only one request can bring all required data.
I am still working on this task, I already created the RecyclerView and I am still working on fetching data from the server and trying to understand how to deal with all of this.
In Narbase they had been using MVVM for a while now as I heard. MVVM stands for “Model-View-ViewModel” which is a software architectural pattern. It’s simply a way to organize your codes to be more testable, maintainable and uneatable and more. So how we can implement MVVM in our codes that will be a topic for another post. So that’s it for this week.
Till next week.
]]>https://narbase.com/2018/09/23/first-sprint/feed/0Relational and Object Oriented Modelshttps://narbase.com/2018/09/17/relational-and-object-oriented-models/
https://narbase.com/2018/09/17/relational-and-object-oriented-models/#respondMon, 17 Sep 2018 06:05:16 +0000https://narbase.com/?p=526This week I had to implement a backend that stores report templates and filled reports in a database. Because I am used to thinking of data in a hierarchical way, I directly envisioned the template as containing entries of various kinds, a title, and the like. This is easily obtained in an OO design as an object with a lot of entries, and these entries are objects of classes that extend a general entry class. So far so good, but I wasn’t sure how to store this in a relational database and my implementation seemed more like it OO counterpart than I like.

The main issue though comes to transitioning between the two representations (or three if you include the JSON representation used to communicate the data with the frontend devices). I am using the Data Access Objects provided by the Exposed library to interface with the database. I found myself creating an additional set of classes that implement my hierarchical design and control the order in which the DAOs are created, how they linked, how they are stored, and how they are retrieved. I am rather uncomfortable with the design of these classes so far. It feels that I am making more effort than I should. Maybe I am not utilizing the relational model perfectly or maybe my data is more suited to other alternatives like some NoSQL Dbs. I will look into it and keep you posted.

]]>https://narbase.com/2018/09/17/relational-and-object-oriented-models/feed/0New Project: My First Projecthttps://narbase.com/2018/09/15/new-project-my-first-project/
https://narbase.com/2018/09/15/new-project-my-first-project/#respondSat, 15 Sep 2018 16:14:46 +0000https://narbase.com/?p=512At the start of the last week my new colleague Ayman and I had a small meeting with Islam and he talked to us about a new project Ayman and I will be working on it. He gave us an introduction about the project, the benefits of the project, and who we are targeting with this project. Islam told us we will work in a scrum fashion with a weekly sprint.
Scrum and sprint were just some technical terms to me and I had to know what they actually mean. At first to build a product you need somehow to manage the process of building that product -your project-, and there are many techniques and methodologies to manage your project such as waterfall methodology, Agile methodology .. etc. Waterfall methodology requires to complete an entire phase before going to the next phase. You start with the planning the whole project and sometimes without even having the complete vision of the final product and then start developing the product ..etc. This could take months and a minor problem takes you back to the previous phase and more time wasting, and by the time you deliver your product to the market you may found that it’s already too late, especially if you are in the Software business, and here comes Agile. If you are in the Software development industry you must hear of Agile which is wildly used among other methodologies. Agile simply is a set of methods and practices used as a tool to manage software projects and is preferred because it’s flexible and adaptive to changes, faster development and more.
Back to scrum, Scrum is an agile project management methodology or framework that used primarily in software development projects, it’s used to increase the effectiveness of team collaboration on complex products and complex problems and deliver new capability and features to your product every 2 – 4 weeks (which called sprint) with the highest value. So basically you do enough planning to get started and then start building, testing and then reviewing and do that again with new capabilities.
In Scrum there are three key roles that are needed; the product owner that define the features that are needed in the product, the scrum master is kind of the leader for the team, running the meeting and keeping things going, and finally the team itself that will be working on the project.
There are 3 artifacts or documents that are used in Scrum. First, the product backlog where featured got prioritized known as user stories that could go into the product and it can evolve and change with every sprint; user stories are a way of describing a feature. Second, the sprint backlog which contains the highest priority user stories, they get estimated for size and committed for the next sprint. Third, the Burndown Chart to show the progress during a spring on the completion of tasks in the sprint backlog, this chart should reach zero points as the work is being completed.
There are lots of things about Scrum and I just gave you a glimpse of it, so if you got interested in the Scrum methodology you will find tremendous resources online.
Regarding the project, I will be responsible for the Android application side and Ayman will work on the Server side.
Our first task was to start drafting the backlog. After finishing our first draft of the backlog Ayman and I started working on the APIs. Now there is a server and the application will make a communication with the server we need to agree on sets of APIs, so we can be on the same page in terms of communication and understanding each other. But what do I mean by an API?
Applications connect with each other to allow us to book a Mishwar ride and order our favorite food from our favorite restaurants with just some types and clicks, that won’t be possible without the APIs. API stands for “Application Program Interface, API is the messenger that takes request and tell the system what you want to do, and then returns the response back to you. You can say API is a software intermediary that allows two applications to communicate with each other. Each time you use Instagram or check the weather on your phone, you are using an API.
Last week Islam also gave me access to related codes in GitLab that I can use in the project and I start working on them. These codes were written in Kotlin.
But what is GitLab and what is Kotlin, and how I start learning Kotlin and also what I learned from these codes. These topics are for other posts. So that’s it for this week.
Till next week.
]]>https://narbase.com/2018/09/15/new-project-my-first-project/feed/0Database Migration Toolshttps://narbase.com/2018/09/15/database-migration-tools/
https://narbase.com/2018/09/15/database-migration-tools/#respondSat, 15 Sep 2018 16:02:07 +0000https://narbase.com/?p=507Narbase always looks for ways to improve the workflow and quality of their projects. Having been away from the core members of the team for a while, I found they made many changes making programming easier, cleaner, and more efficient. These include utilizing coroutines to get rid of the tangle of callbacks that plagued the codebase before, using MVVM and data binding to ease the use of ui elements in Android, and using exposed for database access from the server code. The last one was chosen in place of Jooq. But Jooq, despite its shortcomings, could easily be integrated with a migration tool named Flyway. Exposed on the other hand doesn’t seem to suggest any widely accepted migration tool, so it seems we should make one.
Database (Schema) migration tools are useful to manage the changes in the schema accross time in a way similar to how version control sytems like git manages the changes in the code. There are different interesting migrations systems imbedded in popular frameworks like Laravel and Django. There is also one in the Android Room persistence library. Looking at these tools I felt that the simplest decent form of our migration tool would be implementing migrations as objects implementing up and down abstract functions that uses any database abstraction (exposed in our case) to upgrade or downgrade the schema. The tool can hash a selected query (for mysql it can utilize the schema information table) to check whether the schema has been changed externally.

Generally this seems fine but I am not sure how to combine this with exposed where a lot of the schema changes occur in their own classes. Furthermore, there is already a tool (Harmonica) that does a lot of what we want but, in my opinion, doesn’t handle exposed in a satisfying way. Finally, since exposed schema changes happen in code, it might be possible to manage them to some extent using traditional vcs with tags for example. So, for example developing a Django style migration tool to exposed might not be worth it.

I will give it further thought, discuss it with colleagues, and keep you posted.