Writing Better Software

Hey everyone!

Just wanted to update that launching an app was a success! It was hard work from the start, but everything went smoothly as the time kept going on!

This is with the same company I’m still working at. I’ll have to say that everybody (the company plus the team I am in) put in their best efforts to make it all happen. It’s not live to the public yet, but when it will be then I’ll put a link under one of my future posts. It wasn’t like this along with just a business, but as I’ve been working here, everybody was basically a family. That was probably what made everything more comfortable.

Anyway, although our CTO didn’t exactly mind too much about coding style, I had adapted to these standards that helped a lot with bugs:

Though I didn’t like the old code I had to work with, I still did my best keeping at it and using it, just because it was still working.
While adding newer portions into the app, I started to incorporate the standard style of what Android wants.
Simplify/reuse/do as less in code as possible (meaning don’t rewrite code in other places) and just let what you’ve written before work for you whether it will be now or the future.
Remove anything unnecessary and refactor as much as possible, especially when an opportunity can be seen to do it!
Go out for breaks if necessary to feel refreshed as you come back into the office.
Do what’s only necessary for the code reviews!

Let’s get to the why the above needs to be done:
First, of course there will be legacy code hanging around (unless you’re one of the lucky guys out there who has started the project). However, don’t let you being first get into your head and make sure it is simple enough.
Secondly, you should try and think for the other developers who need to work along with your code. If they don’t understand something and will have to ask you all the time, that will be super not-productive for you to work on something else. That goes along with being simple enough.
Third, also going along with being simple enough, if you’ll have to come back to a feature in the next 4 months, chances are you’re not going to remember all of the details (who does if they’re working on multiple tasks?). There may be geniuses out there who can do that, but training yourself to do so is probably not worth it due to healthy-lifestyle reasons.
Fourth, you know that you’ll be shooting yourself in the foot when you find something that just doesn’t seem right (or if somebody else does and then points it out to you – however if you’re learning from that then that’s good!)
Fifth, it’ll be less-likelier to introduce bugs if the code is just simple.

Just remember that it’s not hard to program. Rather, solving the problem through programming is the challenge.

Until next time.
Brian.

Hey everyone,

Do you guys feel good already with the level that you are at? Maybe you feel as if everything is done and then there’s nothing left to do.

In reality, there’s always something that will be left for you to do. Always make sure that there are bugs that will be filed, and always try and find something yourself. Because although you write good code, it might not work the way you want it to work.

Always try and consider all the possible scenarios that you can find. For instance, using a scrollable TabLayout will work fine on left-to-right alignments, but not right-to-left. Though you can find libraries that will alleviate this issue on Android, Xamarin.Android does not have this support and you’ll have to do the port yourself.

However, if you can do the port by yourself, then you will be able to benefit from learning about what’s going on with the code you’re writing! It’s a tedious process trying to debug, but you’ll thank yourself later because of how you solely did it.

Afterwards, show some love for the other developers who may struggle with the same issue. Put it up on GitHub and try to make a binding for it. If you really want to benefit others not by using the NuGet sources, then create a readme on how to make the binding work for all others.

Or, just drop the source onto GitHub and then people will notice. Once that happens, you’ll be able to generate an audience that will give you a sense of accomplishment.

That’s all I have for today, and therefore, until next time!

Brian.

Hey everyone,

Short post, but ever come across people that you feel are toxic? Especially with those who think they are right almost all of the time?

Yes, there are such people who we sometimes will have to deal with. The big egos are what gets others feeling left out, and yet it’s hard to communicate with. They’ll tell one thing, and then in the next hour or 2 they will say something else.

Yes, we should always strive for the simplest solution, but sometimes what we perceive as simplest is not enough.

Sometimes it is best just to suck it up, try and do what they want, and then move on.

Of course, do what they want in the simplest solution. I wouldn’t worry too much about it since designs can usually change anyway, as there is always going to be something that they won’t like.

Just make sure that you are working on yourself since the value of who you are should be to make sure that everybody is happy with what you’re doing. Pushing forward is the best thing for yourself no matter the situation. Just remember to program happily and live well!

That’ all I have, so until next time!

Brian.

Hey everyone,

Ever had this one time when a person comes on a project and merges in your code, but at the same time he or she doesn’t exactly understand why something is written that way?

For example, you’re preserving a variable to use it in other methods since only one method gives you some parameter that you can use?

To an extent, we all do it all the time. However, it has to be done with good purpose. Otherwise if there’s no point, then don’t do something that’s extra and unnecessary.

It’s fine to make quick fixes, but at the same time minimize with diverging what an API gives you out of the box.

Therefore, being smart about doing something is not enough to go about solving problems. If there’s a way to do it via an API, then it should be done that way.

I’ve been told times that things should be done the way they need to be done, and the constraint should follow with the system.

Another example: there’s an Android design that you’ve been given, however it is not something viable via the Material Design guidelines.

Just like Apple, Google will frown upon doing something entirely outside of the specs given. Therefore, if you want your app to be featured, then make sure it is strictly within specs.

People who have iOS experience strictly enforce the rule of following the specs, and therefore coming to Android they’ll follow what is given in its API at the same time.

This makes sense for the next developer to also follow along with your code so that everybody can be productive at the same time.

I’m not saying don’t make the app outside of the specs if there’s some difference of about 15%. There are exceptions to this rule, but if you’re out of bounds, then it’s best to start rethinking how you’re writing your app.

That’s all I have and I hope this helped you to write something better. Leave comments below for questions or suggestions.

Until next time!

Brian.

Hi guys!

Today is mostly just to express my thoughts out loud.

I was invited to a late night party last night with a friend of mine who also happens to be a software developer. The party consisted along with his relatives. We work in the same building, but just in different companies.

I joined in and had a pretty good time. That was how I felt to myself. We played pool, both my girlfriend and I did our best to socialize, but most of all I just wanted to relax and think about how work is pretty awesome.

One of his younger cousins also introduced himself to me. He seemed quite friendly, quite active, quite loud, and for sure is very talkative. He thought something was amiss that I didn’t have a good time because I wasn’t smiling.

Maybe it was because that was his first impression of me and just thought of it that way.

I was thinking that it could possibly be due to how scientists and engineers usually like to think about problems, whether they will be about work or about something else. My friend really had a good time! He had to ask about how I was doing as well, and truthfully I couldn’t complain about anything.

I guess thinking more logically, I think that smiling should come along with a purpose. He gave me his cousin’s thoughts.

There were plenty of reasons that I couldn’t smile enough. First, I was thinking about work. Second, I had not slept late in a long time. Third, I of course was tired and couldn’t socialize at my maximum.

This got me thinking that developing good habits are important to a person’s health. Now that I’m an early bird, it probably helps me develop my thinking into a specific pattern and reorganizes myself. However, different people have different perspectives to good and/or bad habits. But the good habits for me helps with efficiency.

That’s all I have for today. Leave some thoughts in the comments below and share them as well.

Until next time!

Brian.

Hello there!

Once upon a time, somebody told me the notion which “LINQ can do anything!”

For those who have not yet used LINQ, the basis of it is to transform a collection (e.g. arrays, lists) into another form of collection, or filter out from a collection.

So what needs to be done in order to use it? I will have faith in which almost everybody knows how to use SQL. We don’t need to do anything complicated, just on a very base level of knowledge will be fine. Keywords that should be familiar are from, where, select.

Let’s jump to it. Say that we have a list of strings with such names:
Hugh, Lisa, Shawn, Pamela, Anthony

Now let’s say we want to filter out Pamela. For most Java only thinkers who would probably write a method to do that (I used to be such a person myself), which looks like


public List FilterFromNames(List originalList, string filterName)
{
var list = new List();
foreach (var name in originalList)
{
if (name != filterName)
{
list.Add(name);
}
}
return list;
}


We will be returned a new collection modified from the original list that we have passed in, and say we called var modifiedList = FilterFromNames(myList, "Pamela");. However in any production-code, we’ll want to try and avoid something like the above since if we’re just going to make a function for one thing, then it should be something viable like passing in a username and password field for different applications.

Instead, we can use LINQ for pretty much the same purpose. Let’s do that and try and get an understanding of an under layer of how it works. There are two types of LINQ: method and comprehension.

In method syntax, we’ll rewrite the above like so:
var modifiedList = myList.Where(name => name != "Pamela").Select(name => name).ToList();

Let’s look at what’s happening here. Since LINQ supports any collection and using any of its methods will return an IEnumerable collection type, our modifiedList is just that as we are calling Where(). Within our function argument, we have a lambda with a variable which we call “name”, and we’ve also explicitly said it is not the same as “Pamela”. From here, we’ve done a selection by calling Select(), also returning an IEnumerable. We also have a lambda with a variable called “name” here, and we return everything that we need as the selection is run.

Really, we don’t care what variable is named in our lambda functions, but I purposely made it readable for viewers. However, we can write it like this and still yield the same result:
var modifiedList = myList.Where(x => x != "Pamela").Select(y => y).ToList();

Or, if any reason it is preferred to write comprehensively, this will yield the same result:
var modifiedList = from x in myList where x != "Pamela" select x;

And there you have LINQ in a nutshell! 🙂

Until next time!
Brian.

Hello again!

We’ll dive mainly into coding today.

This is part 2 of Reactive Extensions… in Xamarin Android???. Check that out if you’re interested in a little bit of history and use cases, or feel free to skip if you just want to dive into the bits and pieces of the code.

In reactive extensions, there is a timeline of events of what’s happening with something. We can take a real life example in which a person takes his/her wallet and dirty clothes, goes to the laundromat, washes the clothes, dries the clothes, puts them in the car, goes to the supermarket, buys food, and finally goes home with everything completed in the check list.

We’ll put this in the observer/observable pattern. The observable is the person in question. The observer is the follower of the story.

We’ll keep it simple by taking the example above with a shorter list of things to do: person exits his/her home, person goes to the supermarket, then person goes back home.

using System.IO;
using System;
using System.Reactive;
using System.Reactive.Subjects;

class Person
{
    Subject whenFinished = new Subject();
    IObservable WhenFinished => whenFinished;
    
    int step;
    
    void ExitHome()
    {
        // person exits home
        step = 1;
        whenFinished.OnNext(false);
    }
    
    void EnterSupermarket()
    {
        // person enters supermarket
        step = 2;
        whenFinished.OnNext(false);
    }
    
    void GoHome() {
        // done with tasks
        whenFinished.OnNext(true);
    }
    
    static void Main()
    {
        WhenFinished
        .Subscribe(finished => {
            string message;
            if (finished)
            {
                message = "finished";
            }
            else
            {
                switch (step)
                {
                    case 1:
                        message = "entering supermarket";
                        EnterSupermarket();
                        break;
                    case 2:
                        message = "going home";
                        GoHome();
                        break;
                    default:
                        message = "doing something else";
                        break;
                }
            }
            
            Console.WriteLine(message);
        });

        ExitHome();
    }
}

Let’s take a look at what’s happening here. We’ve made a subject that is a tracker to find the state of the person which is, in this case, the observer. Our observable lets us know if any updates are coming into the object, or rather, returning the subject. In our main method, we first initially subscribe to any events being pushed. No activity is being made at this time, that is until we call our ExitHome(); method.

Now as this method is being executed, it means we are updating our step to 1. Our observer then calls the OnNext(bool); method, triggering our code to run within the WhenFinished.Subscribe(...) method. The parameter finished, in this case, would be false because we passed in false as a parameter in our call to OnNext(...);. Now, since the step is 1, we call EnterSupermarket();, which updates our step to 2. Similar happens with step 1, except now it jumps to step 2 calling GoHome(); in the process. Now because GoHome(); passes in true within the OnNext(...); call, our subscription is done, at least for now…

So basically, anytime there is an observer and observable, with the observer calling OnNext(...);, the observable will always subscribe to it.

This can be used in any Xamarin codebase as long as the libraries are referenced. Please let me know in the comments below if you’d like more examples of such.

Until next time!

Brian.

Hello all!!!

You’ve probably heard of RxAndroid and have already played with it, I’d imagine. Yes?

You’ve probably never thought of using reactive extensions in Xamarin because… it is just something different entirely…

Well, if you didn’t know, here’s the not-so secret surprise. Reactive extensions have already long existed within the .NET framework since version 4.0, so the good estimate was in 2011. That’s long before RxAndroid started to exist which was mid 2013 observing its commit log!

Therefore, it is really nothing new for functional-oriented programmers. It’s however a very new concept to object-oriented programmers since its style is especially looking for events in some interesting thing.

Depending on the purposes of what your code wants to achieve, sometimes object-oriented principles will play in better than reactive extensions, and the same is true vice-versa.

Usually with object-orientation, if we are passing an object as an input value, then an output value will be given by using this object possibly also giving the ability to change it. In reactive extensions, we have a timeline of events that look for what gets in, and then we get an output.

We’ll go in deeper into the subject in a different blog post.

Merry Christmas, and until next time!

Brian.

Hello again!

Today, I’d like to talk about how another set of eyes will also help.

If you’ve been writing code mainly by yourself, you may think that it’s good because it works!

Some day, you or another person will have to go back to the code that you’ve written before, and if that pile of beauty as you’d call it is good because you’re the only person who has written it, then you’ll probably end up in more serious troubles in the future.

You’ll be lucky if there’s another nice and serious developer who has had a lot of miles ahead of him and will help you to look at what you could’ve done better. This is also a part of their job in order to help you grow.

This is not to say that they don’t write code that is hard to understand. Everybody is human and nobody is perfect. Therefore, we can think of it this way in which a person writes an essay. The first draft is not perfect. The second draft is a little bit better. The third draft gets better than the second draft. The final draft is the best.

In code, drafts are like release versions of an application. The first release will almost always have something that sucks. This is why there are so many iterations of releases in all the software that we see, in which, there’s never a final draft. The problem is, with big software applications, there’s a high chance in which some code in there would be considered as spaghetti – this should just be a rough draft where refactors will be needed later on.

We’ve always been taught in college that when writing essays, they should be clear and concise. This is the same with any profession. Dancers should know their techniques well which will give them the correct posture to perform. Singers should know how their voices work so that their larynx will not hurt. Programmers must always try to make their code readable and understandable. All of the clarity and conciseness takes time and practice.

I do still find myself making things more complex than it needs to be along with others in the team that I work with. Having others catch them and then showing how they’ve simplified it definitely helps along the way.

And the last thing I’ll add is as long as you’ll be working well with others, you’ll find no problems at all.

Until next time!

Brian.

Hi all!

Remember this one time where you had first jumped on the code base when you started a job?

Then remember also how much spaghetti code there was and that it could be a lot simpler?

Chances are that the 5000 lines of code to slim down becoming 500 lines will take quite a bit of time and effort to achieve.

However, that’s okay, especially when there will be more time down the future of a project. Nobody should be doomed working with legacy code.

Therefore, a good way would be to introduce a new concept somewhere in the middle of the project.

Here’s an example: I was pretty new to Xamarin, but I’m not that new to Android development. The concept of how things were working gave me a pretty good idea of how the code base kept working together.

I saw some things that definitely were able to use improvements. We had a colleague learning Android development at the time using fragments in order to reinvent the navigation drawer… there was a header fragment to reproduce the hamburger, back button, menu options, etc…, and body fragment for everything which was pretty much overkill. It was quite messy along with the extra classes and variables that were not really needed.

As I became much more familiar with Xamarin’s capabilities, I decided that it was a good time to introduce the CoordinatorLayout along with the real Toolbar. I reused the body fragments that had all the functionality within them. It didn’t take long to do 80% of the port at the time.

Then there came a design change in which the time to make all of those changes for myself weren’t very feasible to do alone. It’s quite fun to see that there were quick-and-dirty solutions in order to achieve all of the possible use-cases that were needed. Therefore for me, it was better to work with what I had in this case.

Time went on and we started adding a couple more people on the project I was solely working on. As resources grew, I started telling someone else also familiar with the concept about what I was trying to achieve. He started to jump on it straight away, while I’m now fixing bugs towards the day of releasing the app. As the app is still in progress, stay tuned for updates!

Anyway, here are some of the takeaways from this experience that I’ve gained:
– You learn other possibilities to try and make something using an already existing concept out there.
– You become very excited about how another person with more experience actually works on what you’ve started and starts to work along with you.
– You just keep getting better each time.

Therefore, don’t cringe and cry on that new project! Just work with it, and you’ll find an amazing experience along the way.

Until next time!

Brian.