Two new posts

draft: open-source: the good, the bad, the ugly
not-published: firefox os experience
This commit is contained in:
Mahdi Dibaiee 2015-10-22 23:17:13 +03:30
parent f577d6c9c5
commit 1f38e2a6d7
4 changed files with 119 additions and 0 deletions

View File

@ -0,0 +1,34 @@
---
layout: post
title: "My Experience Developing an Application for Firefox OS"
date: 2015-09-08 02:06:00
permalink: firefox-os-development-experience
categories: experience, firefox-os
published: false
---
So, I made my first actual product, Hawk. It all started by installing Firefox OS on my Nexus 4 just to try it out.
I searched Marketplace for essential apps I would install on Android, well,
a File Manager is necessary, I found [this](https://github.com/elfoxero/file-manager) which is good but it lacks a lot.
I was wondering if I could write a File Managercreating was not my only intention.
I thought I would use React Redux stack and learn it on the way.
So I did, I wrote a File Manager which I personally think looks good and has good functionality (I have a lot of ideas to be applied).
I learned React Redux, too, in my opinion it's a good pattern but I think some parts of it can be improved further.
Anyways, I'm here to talk about my experience writing a Firefox OS Application.
*TL;DR: You feel right at home, debugging tools are great (WebIDE), but a little buggy sometimes.
You can use latest web features without worrying about cross-platform and these shits. The overall OS performance is lower than expected.*
#Home, Sweet Home
Writing mobile applications using Web technologies without having to worry about *porting* things,
banging your head against old webkit's weird behaviors and compatibility issues with old devices (looking at you, PhoneGap) feels great.
One thing I really like about Firefox and Firefox OS is most new and spicy JavaScript features are supported and you don't have to prefix anything.
Although I think performance of CSS animations/transitions can be improved on Firefox (they're faster on Chrome I think), you won't have much problem
writing applications for Firefox OS, I used a lot of transitions and animations in my application.
#Tools

View File

@ -0,0 +1,85 @@
---
layout: post
title: "Open-source: The Good, The Bad, The Ugly"
date: 2015-10-13 06:15:00
permalink: open-source-good-bad-ugly
categories: experience, open-source, opinion
draft: true
---
I have been doing Open-source for a while, I don't call myself an "expert" or something like that,
but I'd like to share my opinion on contributing/maintaining open-source code.
So, I've been following and contributing to open-source projects for quite a time,
and I have had different experiences each and every time. There always are good experiences and bad experiences
along a road, it's never a heaven, never a hell. I've had contributions as small as fixing a typo in README, or as big
as adding a new feature to Firefox Developer Tools or refactoring a whole repository!
Here I'm going to share my experiences and what I've learned along the way that you should consider
if you want to take this road.
The Good
--------
I love open-source, it's awesome how people share their efforts with others, and others give feedback to
the maintainer to make the software better. It's an always-growing system, even if a maintainer stops maintaining,
it's possible to _fork_ a repository and continue it, although not as easy, but possible.
The best part of doing open-source, in my opinion, is building connections and learning from others.
Whether you are maintaining or contributing to a project, you are going to learn new things, it just happens.
If you are a maintainer of a repository with a countable amount of users, you are going to constantly learn your mistakes from others,
finding these mistakes by yourself is really hard, because you can't easily look at a subject _the other way_,
but users have this potential to look at your code with their eyes, seeing mistakes you can't see.
If you are contributing, following or just exploring projects, you are definitely going to learn from the events in project, the solutions people suggest to a problem,
the way they communicate, etc.
Usually, not always, the maintainer has a better knowledge over the subject of project than you, so you are going to learn from him and other contributors
by reading their code or exploring the issues and how they've been solved. I personally learned a lot this way. I would volunteer to fix a bug, then the maintainer and other contributors would show up to give their suggestions and ideas on the issue, which I would learn from. I also subscribe to interesting issues that I don't know how to fix to see how they get solved.
The Bad
-------
First off, the most annoying thing about open-source contributions is that people (I'm looking at you, maintainers) think
that contributors are jobless bored people who don't know how to spend their time and have come to waste some time on some random open-source project, NO, seriously.
I have a job, I totally care about my time and I'm not making a Pull-request because I'm bored.
Now, why is that important to know, it has happened to me a couple of times that I ask on an issue:
_"- Okay, I'm interested, what **exactly** has to be done?"_
_"- Great, please do x, y, z"_
_... some time later_
_"- Here is x, y and z, please review and merge"
_"- Oh, thank you very much, but you know, now that I think of it, I don't want x, y or even z. Closing."
and I'm like:
![Are you kidding me?](/img/are-you-kidding-me.jpg)
{% include 'caption.html' text='Are you fucking kidding me?' %}
This is the worst thing that can happen to you, try to avoid it, you don't want your valuable time wasted.
How to avoid it you ask, there is a sign that I've found which leads to this problem most of the time and that's **lack of clear specification**, just like with clients, if the maintainer doesn't specify what should be done, you should stop.
It happened to me, just like the past discussion, except he didn't tell me _"Please do x, y, z"_, he made himself look
too busy and said: _"The title says it all"_, no, it doesn't say it all. "x, y and z" can be implemented in `2^9` ways, and sadly,
you are not going to accept the `192`th way, as you "don't like it". Do not get trapped in these time-wasting situations, I wish maintainers understand how valuable peoples' times are.
The Ugly
--------
The sad part about open-source is, if the maintainer decides not to support the project anymore,
people will _kind of_ suffer. If the maintainer abandons the project, the project is *almost* doomed, as forking and continuing is really hard, reading the code from bottom up and understanding it isn't easy, and as there is no outcome, people usually decide to abandon a project once they lose interest in the topic.
If I personally lose interest in a project I've made, I'll abandon it, I will try to guide new users through but I usually
don't offer as much support, I have more important things to do, it's really sad, but true.
To prevent this from happening, you must be able to make money out of your project, or your project must be really interesting
and challenging to keep you working on it.

BIN
img/.DS_Store vendored

Binary file not shown.

BIN
img/are-you-kidding-me.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 52 KiB