For the curious: What made me write this post:
A very good friend of mine called me up today and asked me to go through a web portal that their company is developing to gather some feedback about it. When I opened the page I was quite impressed at first site and everything about the visual styling to the page layout frankly looked quite awesome.
Being a web developer myself, I somehow couldn’t resist the urge of opening up the browser’s developer tools to check out code behind it, and this is where the problems started showing up. As soon as the developer tools window pane opened up eating up half of my screen estate, I noticed the page layout completely fall apart. There was a mess of overlapping texts, visual elements, and what not all over the page rendering the site completely useless.
By instinct I ended up opening the style editor of developer tools to check the CSS to find out where things where breaking, however what I saw was nothing but plain horror for any front-end developer . It had to be one of the most messed up style-sheets I have ever seen! Basically it was nothing but a garbled up mess of style definitions for classes, ids, media queries, etc. What made it even more insane was that there was no homogeneity to the way the document was written, no indentations and to top it all the whole site had the most generically confusing class names that one could ever have nightmares of.
So, I called up my friend to congratulate him about having such a gem of a front end guy work on his team, when I came to know about the most sorry part of the whole story. The person who wrote this code was apparently a man who had quite a large number of years worth of “industry experience” and has been doing front end work since before even I knew what HTML/CSS was!
This is what convinced me to go ahead and post a few simple things about things that one should keep in mind while writing code with a bit of an inclination towards CSS.
For the Restless, Here’s what I want to say:
Here are a few best practices that I personally follow that I’d like to share with everyone:-
- Always remember that any code that you write has a high probability of being extended or needing maintenance in the long term. 70% of most maintenance woes can be avoided by keeping this simple fact in mind while writing code.
- As a direct consequence of this, make sure that whatever code that you write is readable even to the most novice coders out there.
- Adopt good variable naming practices [eg. a variable name “count” is always more desirable than a variable name “i” for a counter variable since it’s name gives a good idea about it’s functionality.]
- Try and write self documenting code, with enough [read: not too less, yet not too much] comments describing what a certain block of code does, and how it does that. The best way to make sure that the comments are of the perfect length would be to make sure that the comments for a block of around 5-10 lines of code is never longer than 2 lines [of 80 characters each].
- One of the places which very often make the biggest mistakes in documenting stuff are the CSS files. A CSS file with a spaghetti mixture of ids, classes, etc. is never a good idea.
- Always try to have a proper document structure for the CSS with logical grouping of style definitions, preferably with an index comment at the very beginning. This helps make the code more readable and thus much more easy to maintain and extend in the long run.
- Indentation is your biggest friend – It helps make the code more easily readable as well as create a well-structured document format. Indentation makes it dead simple to understand the flow of logic within the program and separated different logical groups from each other by creating well nested content for the document.
- Lastly, and more importantly before signing off a piece of code as ready for production, be honest to yourself and ask yourself: “Is this the kind of code that I would like to read through and work upon in a few years time when I have forgotten the minutes of the implimentation?”
I sincerely this helps atleast a few people to understand what it is like to write beautiful code and give them a brief idea about how to do so themselves.
Are you a Fedora user who wants to check out the new Australis Theme for Firefox scheduled for release with Firefox 28? However, you are a bit apprehensive of letting go that stable release of Firefox in bundled within your Fedora installation by default, just in case something goes wrong with the nightly beta release.
If this is what defines your current dilemma, fear not. You can have both the stable as well as the nightly beta versions installed simultaneously in your computer in a few simple steps without any trouble at all! Here’s how to do it in case of Firefox Nightly version 28 [the latest release at the time of writing this post]:-
Step 1: Login as Super User:-
Step 2: Get the nightly package:-
Go to http://nightly.mozilla.org to get the latest available nightly build for your system.
Alternatively, you can use the command line tool wget to directly download it via the command line as follows:-
Step 3: Extract the contents of the tar ball as follows:-
#tar -xvf firefox-28.0a1.en-US.linux-x86_64.tar.bz2
Step 4: Rename the extracted directory to “nightly”:-
#mv firefox nightly
Step 4: Create an installation directory:-
Step 5: Move the contents of the “nightly” directory to the installation directory:-
#mv /nightly /opt/firefox/nightly
Step 6: Create a Symbolic link for the Nightly installation:-
#ln -s /opt/firefox/nightly/firefox /usr/local/bin/nightly
Step 7:Run Firefox Nightly by typing the following within the command line or the alt+f2 launcher:-
For command line: $nightly
For alt+f2: nightly
Step 8: Relax and enjoy the Australis awesomeness! 🙂
Here’s a list of command line steps to install Skype on Fedora 19:-
Step 1: Open up the terminal and switch to super user:
Step 2: Install the dependencies:
yum install alsa-lib.i686 fontconfig.i686 freetype.i686 glib2.i686 libSM.i686 libXScrnSaver.i686 libXi.i686 libXrandr.i686 libXrender.i686 libXv.i686 libstdc++.i686 pulseaudio-libs.i686 qt.i686 qt-x11.i686 qtwebkit.i686 zlib.i686
Step 3: Download Skype 4.2 Dynamic package for Fedora into /tmp:
wget –trust-server-names http://www.skype.com/go/getskype-linux-dynamic
Step 4: Extract the Skype 4.2 package to /opt:
tar xvf skype-4.2* -C /opt/skype –strip-components=1
Step 5: Create Launcher, Link icons, language and sounds:
ln -s /opt/skype/skype.desktop /usr/share/applications/skype.desktop
ln -s /opt/skype/icons/SkypeBlue_48x48.png /usr/share/icons/skype.png
ln -s /opt/skype/icons/SkypeBlue_48x48.png /usr/share/pixmaps/skype.png
chmod 755 /usr/bin/skype
Open /usr/bin/skype with text editor and add following content:
$SKYPE_HOME/skype –resources=$SKYPE_HOME $*
Step 6: Congratulate yourself! You have successfully installed a non-free proprietary software on top of free Open Source software and bent down to corporate needs. Now go ahead and configure Skype according to your needs!
Earlier this year from August 30th to September 1st, 2013, I was invited to Madrid, Spain, to take part in Mozilla Reps Camp as a Mozilla Reps mentor to discuss the roadmap ahead for the Mozilla Reps Program.
ReMo Camp is an annual event / meeting where the leadership of the Mozilla Reps program, comprising of Council members and Reps mentors, meet for 3 days. The meeting comprised of presentations, breakout sessions and discussions to draft the 2013/2014 Mozilla Reps program roadmap. This was the second time the entire program leadership met and worked together in person, the first being in Berlin in 2012.
Even though there were discussions on some pretty serious topics, we made sure that we had our fair share of fun as well, starting from wacky yellow construction jackets to crazy late night wandering in the streets of Madrid.
Amidst all the serious discussions and fun times, one thing that stood out quite prominently was the high spirits that was evident among all the participants throughout the event. I’m sure that future of the Mozilla Reps program is quite bright and secure in the presence of such wonderful people and it is going to grow by leaps and bounds in the upcoming days. 🙂
This blog post celebrates the joy that I feel from the depths of my heart to see that my baby has finally hatched from its shell and come to life for the first time on my Firefox OS Keon developer device.
This is the first post that is being made from an actual Firefox OS device using the WordPress for Firefox OS web application to commemorate the completion of my Google Summer of Code 2013 project!
I’m grateful to have received the opportunity to develop WordPress for Firefox OS (Alpha) – v0.01 as my project for this year’s Google Summer of Code! 🙂
Here’s another three step guide to installing Sublime Text 2 on Fedora 19 – Schrodinger’s Cat:-
- Download the installation script from the following gist.
- Extract it to your home directory [or anywhere you like].
$tar -xvf gist5810101-3b0e9bb3ef5128760df9e3e06877fa4f7e5689ec.tar.gz
- Open your terminal (preferably as super user), navigate to your home directory and execute the shell script.
Voila!! You now have Sublime Text 2 installed on your machine. You may run it from the terminal or via the alt+f2 shortcut by simply typing in “sublime-text”.
Credits to Henrique Moody for the original script gist!!
I’ve simply added a symbolic link at /usr/bin to enable terminal execution. 😉
- Login as Super User:
- Setup rpmfusion:
- Install vlc using the default yum package manager:
- #yum install vlc mozilla-vlc
Voila! You now have VLC media player installed on you computer! 🙂
This is something that I just learned how to do, courtesy of a documentation work that I need to for my college’s fourth semester evaluations, where the requirements state that I need to use Arial / Verdana fonts for my Project Report. The interesting part is that I’m a hardcore Fedora user who uses LibreOffice for all my documentation purposes and as obvious as it may sound, these fonts don’t come pre-installed in Fedora 18. Du-uh? Right? So, I had to distinctly install these fonts on my laptop. How did I do it? Here’s the breakdown.
First here’s a bit of a trivia for those who already don’t know this! (Read: Yack):
Microsoft TrueType fonts (TTFs) are quite commonly found throughout the web, usually specified in stylesheets. However, for Linux users, the most common of these TTFs don’t come pre-installed in most of the common distributions by default. Instead, they are replaced by generic equivalents, usually fallback fonts most commonly defined in stylesheets (again!). This is also true even case of offline documents such as spreadsheets, presentations, or plain .doc files.
Installing TrueType font packages allow you to see content created using these fonts just as the content creator originally intended.
The Microsoft TrueType fonts package includes the following font-families:
- Andale Mono
- Arial Black/Arial (Bold, Italic, Bold Italic)
- Comic Sans MS (Bold)
- Courier New (Bold, Italic, Bold Italic)
- Georgia (Bold, Italic, Bold Italic)
- Times New Roman (Bold, Italic, Bold Italic)
- Trebuchet (Bold, Italic, Bold Italic)
- Verdana (Bold, Italic, Bold Italic)
And here’s the part on how to install these fonts! (Read: Hack):
You can install the MS core fonts by installing the msttcorefonts package. Here’s how to do it. The gist describes what to do, and the commands explain how to do using the Terminal. You may need superuser privileges or sudo configured. :-
- Make sure you have the following rpm-packages installed. Any version should do.
- A package that provides the ttmkfdir utility. For Fedora Core, ttmkfdir should suffice.
- Download the latest msttcorefonts spec file from here.
- Install the cabextract utility.
- sudo yum install rpm-build cabextract
- sudo yum install rpm-build cabextract
- Build the msttcorefonts-2.5-1.noarch.rpm package.
$ sudo rpmbuild -bb msttcorefonts-2.5-1.spec
- Install the fonts:
$ sudo yum install /root/rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm
Introduction tofor WebOS
WordPress for WebOS was a web app which used the WebOS platform’s innovative “Cards” feature, which allowed users to quickly switch between managing, editing, and browsing content. WordPress for WebOS was built around Sliding Panels that enables users to easily switch between creating, editing and managing content.
The app allowed working with both WordPress.com and self-hosted blogs, notified users of new pending comments and had WordPress Stats built in using Jetpack for self-hosted blogs apart from using Sliding Panels to quickly move between new and existing content. It was also the first Open Source WordPress app to have a full visual editor, which made it easier than ever to format text, add links or embed media into a user’s posts and pages.
Even though the project is currently dormant, however, it’s repository still has the potential to serve as a precursor to future Web apps for WordPress, by providing a neat base model for future application developers.
The rising popularity of web based applications along with significant advancements in the Enyo Framework also makes it easier to port the existing code for the web application to newer platforms such as Firefox OS.
Desired Outcomes from the Project during GSoC
- Upgrade the existing Enyo 1.0 based code to the Enyo 2.2 framework.
- Rewrite platform specific code such as app manifest and device APIs.
- Basic UI redesign to a responsive layout so as to support smaller device resolutions.
Aspects of Porting
There are two major aspects which need to be taken into consideration while rebuilding/porting the existing app on a Firefox OS:-
- The WebOS app was written using the Enyo.js 1.0 framework. This needs to be first updated to Enyo 2.2 framework for porting the app to Firefox OS.
- Given the fact that the WebOS app was last updated almost a year ago, the app itself needs some rework to get it up-to-date and at par with the latest WordPress mobile apps on other platforms like Android the latest facelift.
A structured three step approach is proposed for the actual coding cycle as follows:-
- Identify the key differences between the architecture of an app developed on WebOS and that of one developed for Firefox OS.
- Based upon these observations isolate platform specific code and app specific code.
- From here on the actual implementation process begins and is categorized into two categories:-
- Rewrite platform specific code such as app manifests and Web API interactions.
- Modify and upgrade the base Enyo 1.0 code to Enyo 2.2, to include newer functionalities to bring the existing code base at par with the WordPress apps for other platforms such as Android as well as to support advanced features on Firefox OS for the Enyo 2.2 framework. This would include some basic UI redesign to cope with smaller screen resolutions on mobile handsets.
Once the basic code upgradation is complete, the focus can be shifted towards added features based on time availability post completion of primary development objectives. Two major desirable additions would be as follows:-
- UI redesign: Since the WordPress for WebOS app was primarily designed for use in tablets with comparatively higher screen resolutions, the application UI layout needs to be upgraded to a more responsive interface layout to support a variety of screen resolutions most of which are comparatively lower than that of tablets to extend support to smaller devices. A possible layout for lower resolutions can include an arrow button like the Android app to bring out the admin sidebar.
[Note: While the project’s scope for GSoC would include some basic UI adjustments, further improvements to the UI would be a long term goal traversing the completion of the GSoC period.]
- l10n: Localization is a bonus target which can be looked upon if time permits after the primary application development process. Currently the WebOS app supports 11 locales by itself by using JSON based l10n resources identified by the Enyo framework. This section would require a considerable looking into to improve the quality and performance of localized content for the Firefox OS app. The primary objective here would be to extend the current localization resources, however an alternate implementation can be done by using Gaia’s webl10n library if it shows a substantial performance (response/rendering time for localized Glyphs) and quality improvements over Enyo’s base l10n resource implementation.
[Note: This is not a milestone for the project itself, however this is a support feature that needs to be kept in mind for future improvements.]
This is a thought that’s been rather bugging me for sometime now:
Is writing code (programming) via mobile devices really not a very feasible idea?
In the current scenario, almost all conventional programming is done on desktop computers (PCs, laptops and the likes), wherein we have a standard keyboard which is used to write down all the code, and a relatively large enough display device to help us visualize what we are writing. However, with the mercurial rise in popularity of mobile devices we have seen a huge shift from conventionally used devices to mobile devices with almost all major aspects of modern day computing making a gradual yet steady shift towards mobile computing.
We see a lot of developers now focusing on “Programming for mobile devices“, however there is an evident lack of focus on “Programming on mobile devices“, which is actually quite weird in my honest opinion. On one hand we are talking about a truly mobile world, where almost every aspect of computing is being made available for on the go mobile devices. Whereas, on the other hand, for the very basic necessities for enabling these mobile functionalities we fallback to traditional computers (and by traditional, I do take into account laptops as well, because no matter how small in size they may be, they still follow the same desktop oriented norms).
Why is it so that we aren’t yet completely comfortable with the thought of being able to write a piece of code on our mobile handsets? I know some people may argue that it is possible to write code in some ABC language using a XYZ software on a tablet device. However, what I ask is that are you really comfortable with the current scenario? Why can’t we find a nice alternative way to make programming on devices such as mobile handsets more intuitive, organic, comfortable and developer friendly?
The main problem with devices as small as mobile handsets as I see it, is a combination of low resolution / small screen size + lack of a comfortable keyboard / input device. But is it really the main challenge that we are talking abut here? Or is our mindset the main challenge? Is it really that difficult to take on the challenge of redesigning the existing programming methodology and create an efficient solution for mobiles, or is it just that we are just too lazy and or narrow minded to explore the possibilities of programming on mobile devices.
I have heard the proverb which says “Nothing is impossible“, however, I think there’s an even more dangerous public opinion which states “This is not feasible!” which generally results in the eventual death of ideas. But is feasibility really applicable here or should it be the willingness and openness in one’s mind to imagine and realize the things which others might reject as non-feasible and bring about a much needed change in the paradigms? What do you think? Please do leave your thoughts on this as comments below.