Friday, December 19, 2014

A 2-in-1 laptop that just works under Linux: Dell Inspiron 13 7000 Series i7347

For quite some time, I've felt the need for an x86 tablet computer that I could carry with me when I was away from my main workstation. This need became a necessity when I started travelling for business, and while my trusty Bonobo Extreme, from System76, was everything I ever needed for a computer to be, it was also a little too bulky and heavy, which made it almost impractical to operate in tight spaces like in a car - while not driving, of course - and in planes. I knew that I needed something that was modern with a tight form factor like that of a Tablet, yet full featured, unlike many Tablets. 

The ideal tablet computer needed to be cost effective and with known compatibility under Linux 32bit and 64bit. I had considered buying the Surface or the Transformer earlier, but since this was going to be a companion computer and not the primary one, and I needed offline storage to install all my software for when I was on the go, the Surface didn't have enough storage or compatibility to just justify the cost, and in addition to the lack of sufficient storage, the Transformer wasn't powerful enough for my needs.

I discovered Dell Inspiron 13 7000 Series i7347 while researching 2-in-1 laptops on Amazon. After spending time researching it, it seemed like it was created with my needs in mind. The additional $100 off the sticker price of the Dell's original $599 made it an even more attractive purchase I could not afford to miss. I was a purchase I did not regret making.
The laptop is very slick and professional looking, which works great, since I intend to take it with me on my business and family trips instead of my more powerful, yet bulky, 17 inch Bonobo Extreme Laptop/Workstation. The hinges on the Inspiron are very sturdy and the laptop easily folds into a tablet. The touchscreen is very responsive. With a 500 GB hard disk at my disposal, I am able to use all my office productivity applications, as well as, software development tools and related services, without any difficulty. Now granted that this model is not an i7 or even an i5, but neither is it an Atom or ARM based. It provides a full computing experience with enough horsepower for smoother operation and functioning.

Installing Linux on it was a breeze. Almost everything worked right out of the box, and the only hiccup under Linux was, the not-so-well supported Wireless/Bluetooth module with Broadcom chipset. However, with little research, I was able to find Intel's Dual Band AC 7260 module, with the proper form factor, that was compatible and well supported under Linux. A version of that module, 7265, is also listed in Dell's specifications document for this laptop as an option. I suppose, if I had bought this directly from Dell, I might have been able to choose the Intel over the Dell Wifi module.

I also made the right call, when I decided to upgrade the WLAN module myself. The laptop is very easy to upgrade manually. The HDD, the RAM, the battery, and the WLAN module, among other things, are easily accessible, once you unscrew the base lid. On their website, Dell provides a Service Repair guide for this model, which provided all the necessary steps needed to help with the hardware upgrade, and that has only boosted my confidence in this machine and it's quality.

I am very happy with the purchase and would recommend it to anyone who intends to run Linux on it.

The 2-in-1 can be purchased from Amazon using the link below.


Note: there are two form factors the Wifi module is available under. You are looking for the smaller of the two.

7260NGW Intel® Dual Band Wireless-AC 7260 802.11ac, Dual Band, 2x2 Wi-Fi + Bluetooth 4.0

The Wifi Module can be purchased from Amazon using the link below. 



Thank you for reading and I hope you enjoyed the article.

Monday, July 28, 2014

How I learned to program in Scala: The Nexus 5 experiment

Few months back I broke up my long term affair with Mono and I started looking into the the Play Framework from TypeSafe as a replacement stack.

Through Play Framework, I discovered Scala and the wonders of functional programming. My interest grew even deeper when I installed Scala on my laptop and tried some example code in the REPL tool (think Scala interactive shell).

However, I found very soon that I was not able to dedicate enough time during the week to learning Scala due to my full time day job doing .Net development.

Something had to be done.

I thought, I have this wonderfully powerful device on me all the time - my Nexus 5. Surely, I should be able to put it to use to help me spend more time with Scala. So began the experiment.

I rooted my Nexus 5, installed "Linux Deploy" from Google Play Store and installed a chroot Arch Linux environment. I also installed JuiceSSH client and a VNC viewer application. I already had "Terminal IDE" installed which comes with a great android keyboard geared towards software development on Android.

The last piece to the puzzle, I bought a $25 ANKER bluetooth keyboard compatible with my Nexus 5.

I fired up the Arch chroot on my phone, downloaded tmux and vim using pacman and oracle java 7 packages from AUR (some PKGBUILD tweeking was needed).

Then I installed TypeSafe Activator from AUR. I also downloaded vim plugins like vim-scala and CtrlP which proved to be of great help.

It worked!!!

Using the setup described above, I was able to not only learn how to program Scala, I am also able to write software using Play Framework. I can test the same on my phone's browser. The code is backed up on github and I can work on the same codebase from anywhere - as long as I have my Nexus 5 and data connection.

And after the recent KitKat update with Cast Screen - I am able to cast my phone's screen to my big screen HD TV over ChromeCast. This solves the issue of developing on the relatively small Nexus 5 screen.

This experience has made me appreciate VIM, TMUX, and the terminal in general at a whole new level. Even when on my laptop, I now find myself doing more and more coding in VIM instead of IntelliJ.

Think about it, you can now get a decent android box or even a phone, and with a setup similar to what I described, have an almost full fledged development environment. Rich graphical applications can be written in Scala using Swing (sigh) and possibly other graphical toolkits and can be tested within the Arch (or other Linux distro) chroot using VNC.

Side note about Oracle Java instead of OpenJDK: I went with Oracle Java instead of OpenJDK due to an "issue" with OpenJDK on arm chips. Its something to do with JVM running in "mixed mode".

Monday, March 17, 2014

CloudNotes - New project - using the Play Framework

I recently came across the Play Framework and decided to take it for a spin. Needless to say I was amazed. I've decided to use it instead of .Net/Mono on a new project I've recently started work on.
The project is called CloudNotes. The goal of the project is to create a web-based collaborative notes taking and sharing application that is accessible from all platforms. As mentioned above, it'll be built use the Play Framework. I've chosen MongoDB as the database backend for this. LessCssCoffeeScript, and jQuery, all of which come packaged as part of Play Framework, will be used extensively.

Currently, the application features:
  1. Create and share notes using a web interface
  2. Notes dimension and position on screen are stored along with notes - think web based collaborative brainstorming tool
  3. GoogleDocs like collaborative editing of notes, although not yet realtime.
Features, I hope to develop into the application in the coming weeks:
  1. User authentication
  2. Access Control List on Notes and entries
  3. Realtime interface with AJAX calls (currently causes full postbacks)
  4. Mobile and desktop clients
  5. Items reordering
  6. Checklist module
The source code is hosted on github and licensed under GPL v2.
Once complete, I'll probably host a demo on a DigitalOcean droplet.

DigitalOcean offers cloud hosting for as low as $5/month or $0.007/hr for dedicated server with:
  • 512MB Memory
  • 1 Core Processor
  • 20GB SSD Disk
  • 1TB Transfer
  • Additional bandwidth transfer is only 2¢ per GB

Monday, August 26, 2013

Update 1 - Progress so far - IrrlichtDotNet - .Net library for irrlicht that works under Linux

For original article, please go to this article.

After I made the declaration of starting this project on irrlicht forums, roxaz from the forums expressed interest in the project and immediately forked it on github. We bounced around ideas and while I won't yet merge all of his modifications into my repo, I did like many of this ideas and implemented them after tweaking them to fit in with my code. The ideas that I implemented from his repo are:
  1. folder reorganization
  2. a python script that refreshes the CS project file with all the SWIG generated cs files
  3. make.sh file to automate many initial steps
I also spent some time getting myself more familiar with SWIG typemaps and was able to map irr::core::stringc to System.String for almost all instances. These originally got translated to a SWIG generated generic wrapper which wasn't any useful unless you created a companion helper class in C++ to handle the translation both ways between irr::core::stringc and char *, which gets mapped correctly to System.String. Once all occurrences of irr::core::stringc are mapped to System.String, helper class won't be necessary any more. I will also attempt to deploy more typemaps to handle other such mappings in IrrlichtDotNet project.

Friday, July 26, 2013

Linux compatible .Net bindings for irrLicht using SWIG


Ever since I tried IrrLicht, an Open Source 3d Graphics library, I fell in love with it. It is a C++ library and my C++ isn't as good as I'd like it to be and I am more comfortable with C# under .Net.

Since IrrLicht is open source, I figured, someone might have written an .Net binding for it, and I was correct. A few such bindings do exist, although, they are truly only .Net bindings for IrrLicht for Windows platform only.
I also attempted to use MonoGame, which is known to work under Linux, but without any success.

A few days ago, while researching an unrelated subject, I stumbled across SWIG. SWIG stands for Simple Wrapper and Interface Generator. It is used when you want write wrappers to your C/C++ code for other languages. It also happens to support C#. So I decided to give it SWIG a swing and initial results were more than promising.

I decided to test it but exposing the Main method of my C++ test code written to try IrrLicht and called it from a .Net application. It worked!
I decided to take a shot at generating a wrapper for IrrLicht itself. So far, using the bindings that I was able to create with SWIG, I have been able to create simple 3d scenes in C# code.

I've created a project on GitHub to create a Linux compatible .Net binding for IrrLicht using SWIG. The repo is at https://github.com/jimmy00784/IrrlichtDotNet.

Initially, much of the focus will be on creating a Linux centric binding. However, since SWIG is cross platform, if the community is interested in the effort, it could become more cross platform than that.

Sunday, January 20, 2013

Day 2 - Porting nopCommerce to Linux - built in data storage

For some odd reason, I was now able to debug from within MonoDevelop again and that made me happy. Now that the Installation page loaded correctly, I decided to test the SqlServerCe built in data storage for nopCommerce. I provided the email and password, unchecked the "Create sample data" checkbox, selected the "Use built-in data storage (SQL Server Compact)" option and hit Install. Failed.
Setup failed: The requested feature is not implemented.

I set my breakpoint on the InstallController.cs and began walking through the code line by line to see where it had failed. I landed on SqlCeConnectionFactory.cs file line 41.

Contract.Requires(!string.IsNullOrWhiteSpace(providerInvariantName));

I tested the value of the providerInvariantName parameter to see if it was indeed null or whitespace, but it wasn't. For now I decided to comment this line and see if I could proceed. Same error. Examining the stack trace I found that Database.cs in the EntityFramework project had another Contract clause.

Contract.Requires(value != null);

And again, value wasn't null. It seemed like Contract clause wasn't behaving as designed. I decided to comment this one out as well. I found another one in EntityFramework, and then another one. After commenting out quiet a few of these over the next few trial runs, I decided to comment them all using Find and Replace. After fixing some compiler errors EntityFramework compiled without errors. Time to commit changes.

In next run, the application complained that it couldn't find SqlServerCe library. I noticed that Nop.Data project had an entry for System.Data.SqlServerCe.Entity.dll which had dependency issues under Linux. It appeared as though I couldn't get too far with SqlServerCe as the backend driver. I decided to give MS SQL Server a try instead.

In first try I got the familiar Feature Not Implemented error.

Setup failed: The requested feature is not implemented.

However, an empty database did get created. I did a search and commented Contract.Requires from the EntityFramework project. I also set a breakpoint on the FailFast  method in the Environment.cs core file which gets invoked when Contract clause failed.

Setup failed: The provider did not return a ProviderManifest instance.

Examining the stack trace hinted to this location: EntityFramework/Core/Common/DbProviderServices.cs:208.

There was also an inner exception being raised.

Invalid URI: The format of the URI could not be determined: System.Data.Resources.SqlClient.SqlProviderServices.ProviderManifest.xml

Further exploring down the stack trace took me to EntityFramework.SqlServer/SqlProviderManifest.cs:78 which passed a baseURI parameter. For some reason Mono didn't like the value that was being passed. I used an overloaded method that did not require baseURI to see if it'd let me proceed.

Setup failed: The requested feature is not implemented.

This was being raised from the EntityFramework.SqlServer project. I did another search and comment on Contract.Requires this time on the EntityFramework.SqlServer project.

System.StackOverflowException: The requested operation caused a stack overflow.

After another round of placing breakpoints and tracing through the code, I found that the stack overflow was being caused by EntityFramework/Core/Common/Utils/Memorizer.cs:71 when attempting to evaluate result.GetValue(). I surrounded it with a try catch and returned the default value of the generic TResult in case of an exception to see if it'd let me proceed.

Setup failed: An unexpected exception was thrown during validation of 'Name' when invoking System.ComponentModel.DataAnnotations.MaxLengthAttribute.IsValid. See the inner exception for details.

This was coming from EntityFramework/Internal/Validation/ValidationAttributeValidator.cs:75. Inner exception hinted of an unimplemented function.

IsValid(object value) has not been implemented by this class. The preferred entry point is GetValidationResult() and classes should override IsValid(object value, ValidationContext context).

In order to proceed, I forced a ValidationResult of Success.

Setup failed: The handle is invalid.

Reviewing the stack trace took me to EntityFramework/Core/Metadata/Edm/LightweightCodeGenerator.cs:193. Examining the code showed that CreatePropertyGetter was creating a dynamic method to map to the getter method of a property on an Entity. After some more trial and error, it became apparent that while the Type handle was mapping correctly, the RuntimeMethodHandle held an invalid value. Fortunately, the getter method on a property has the naming convention of get_PropertyName. This could come in handy to boot strap this code to allow proceeding further. Time to commit changes and review the work.

I reviewed the database that was created by the application, and I see tables being created. This means that EntityFramework is facilitating table creation which is good news. This is a good stopping point for the day.


Conclusion thus far: SqlServerCe driver won't work under Linux, however, after some heavy tweaking and commenting of EntityFramework code, SqlServer driver does work, at least as far as creating tables.

Thursday, January 17, 2013

Day 1 - Porting nopCommerce to Linux

nopCommerce is an open source, feature rich, and production ready shopping cart and eCommerce solution. They are being used by a number of businesses all over the world as a platform of choice for their webstores. Out of the box, nopCommerce supports MS SQL Server and MS SQL Server Compact Edition as backend database engine. I was researching open source eCommerce solutions when I came across nopCommerce few months ago. NopCommerce peaked my interest as it is written using .Net Framework. While Mono project makes applications written on .Net framework cross platform, it lags behind .Net framework in development and lacks the latest features that .Net framework offers. When I first looked into nopCommerce, Asp.Net MVC 3 was not available for Mono and neither was Entity Framework. nopCommerce utilizes both of these features heavily. This made nopCommerce, an open source solution, not cross platform.

Recently, when the 3.0.3 development branch of Mono made both of these features available, I thought it'd be interesting to try and test Mono framework with its newly added Entity Framework and attempt to run nopCommerce under Linux.

This article will record the changes that were made to get rid of initial compile time errors for nopCommerce, run the application, and get to the Installation page.

Note: When modifying files in MonoDevelop that originate on Windows platform, and when a source control like Git is involved, it is best to not have MonoDevelop change line endings from windows to unix format to keep you commits clean.

Note: The code changes made during this experiment are available on GitHub at https://github.com/jimmy00784/nopCommerce-Linux-Mysql

The primary challenge I face is that in order to utilize Entity Framework and ASP.NET MVC 3 for .Net development, I had to upgrade the stable Mono 2.10.x to Mono 3.0.3 development release. I also had to upgrade MonoDevelop to 3.1.0 development release. This has broken the debugging capabilities from within MonoDevelop.

For porting nopCommerce, initially, I thought that simply switching the .Net Entity Framwork dlls with the Mono's dlls would be enough to run nopCommerce. I downloaded the source code from nopCommerce and loaded it in MonoDevelop. At first glance it didn't look as bad. Looking closely it becomes clear that System.Data.Entity supplied by the project would not work with Mono under Linux and there were dependency issues with EntityFramework and SqlServerCe dlls. I also downloaded the source for EntityFramework for Mono and planned to load EntityFramework as a project instead of simply adding the dll reference to the project. From earlier experience, I knew I'd be making some code changes to the EntityFramework to make it work with nopCommerce.

I added a solution folder for EntityFramework to nopCommerce solution and then added EntityFramework, EntityFramework.SqlServer, and EntityFramework.SqlServerCompact projects to it. For a quick sanity check, I compiled these new projects. EntityFramework complained that the delay sign key provided couldn't be used for assembly signing. That was easily fixed by providing the '-delaysign' compiler arguement. Recompiling didn't cause the same error but instead caused other code related errors, all of which are 'Warning as Error' which could also be fixed by unchecking the "Treat warnings as errors" settings for the project. This fix would also have to be applied to any other projects that complain in similar fashion. Also, the System.Data.SqlServerCe.dll supplied with EntityFramework.SqlServerCompact wasn't compatible with Mono on Linux. I was able to download the file from my Windows installation and that seemed to work ok for the purpose of achieving an error free compilation. The intention here was not to fix the EntityFramework project but to tighten or loosen just enough screws to run nopCommerce under Mono under Linux.

Build: 0 Errors, 54 Warnings.

That's a good place to be. Since EntityFramework project compiled, I commited the changes to the git repository so it would serve as a checkpoint in case I needed to revert any changes I make to the framework.

I replaced the EntityFramework references from the nopCommerce project and use the Entity Framework project as reference instead. Changes would be made only to Nop.Data project and the other projects under the Libraries solution folder for now. I also upgraded the projects from Mono / .Net 4.0 to .Net Framework 4.5 as that's the version EntityFramework would compile under due to other dependencies that are only available under .Net Framework 4.5. Recompiling gave only one error though enough to halt compilation of the project.

Libraries/Nop.Data/Extensions.cs(19,19): Error CS0234: The type or namespace name `Objects' does not exist in the namespace `System.Data'. Are you missing an assembly reference? (CS0234) (Nop.Data)

This was in reference to System.Data.Objects namespace needed on that class. A quick examination revealed that ObjectContext also had an issue and the only way to fix it was to include System.Data.Entity.Core.Objects in the project. This was coming from the EntityFrameworks project I included in the solution. Since I was tracking my changes in Git, I renamed all System.Data.Entity.Core to System.Data to see what it'd do.

Buid: 49 Errors, 34 Warnings.

Most of these were instances of EntityState and DbFunction references complaining for missing System.Data.Entity namespace directive. Many more errors were revealed once these errors were resolved but fortunately those required the same fix. Once all the errors were resolved, I tried replacing the references from EntityFramework.dll, System.Data.Entity.dll, and System.Web.Entity.dll with the EntityFramework project in their place. The changes made to the files under EntityFramework solution folder would only be commited to Git if replacing the Entity Framework references did not generated any namespace related errors.

As mentioned earlier, the projects under the Library solution folders would have to be upgraded to use .Net Framework 4.5 from Mono / .Net 4.0 profile since Entity Framework requires .Net Framework 4.5 features. Similarly projects under the Presentation solution folder would need to be upgraded to use .Net Framework 4.5 and references to EntityFramework.dll and System.Data.Entity.dll would need to be replaced with the project reference to EntityFramework project instead. Since all these projects compiled well without any errors, I commited the changes made to EntityFramework projects to Git.

System.InvalidOperationException
Storage scopes cannot be created when _AppStart is executing.

I had seen this before. A small change in Global.asax.cs file was needed to resolve this. Adding the following lines in the beginning of Application_BeginRequest function and including the necessary namespace references does the trick.

var ob = typeof(AspNetRequestScopeStorageProvider).Assembly.GetType("System.Web.WebPages.WebPageHttpModule").GetProperty("AppStartExecuteCompleted", BindingFlags.NonPublic | BindingFlags.Static);
ob.SetValue(null, true,null);

Giving it another run gave the following error.

System.IO.DirectoryNotFoundException
Directory '/home/karim/MonoDevelopProjects/nopCommerce_2.65_port/nopCommerce-Linux-Mysql/Presentation/Nop.Web/App_DataLocalizationInstallation' not found.

Now I was getting somewhere. Searching for the path reference in the code took me to the InstallationLocalizationService.cs file which passes the location string to webHelper.MapPath method. This took me to MapPath function in the WebHelper.cs file in Nop.Core project. The else block was written for Windows environment. This was done by the .Replace('/', '\\') method. Searching for that string pattern revealed two places total where this was used. I could check for OperatingSystem information before deciding to use the Replace function. Surrounding the code with "if(Environment.OSVersion.Platform != PlatformID.Unix)" should be sufficient. Recompiling gave no errors but running the project again did. It is a different error this time.

System.InvalidOperationException
The view 'Index' or its master was not found or no view engine supports the searched locations.
The following locations were searched:
~/Views/install/Index.aspx
~/Views/install/Index.ascx
~/Views/Shared/Index.aspx
~/Views/Shared/Index.ascx
~/Views/install/Index.cshtml
~/Views/install/Index.vbhtml
~/Views/Shared/Index.cshtml
~/Views/Shared/Index.vbhtml

At first glance it looked counterintuitive because ~/Views/Install/Index.cshtml did exist, but taking a closer look revealed that the system was looking for index with lower case "I" instead of upper case. I changed the URL in the address bar and used Install with upper case "I" and that landed me on the installation page.
After inspecting Global.asax.cs file at Application_BeginRequest, I found that one of the first thing the application does (ignoring the _AppStart fix) is EnsureDatabaseIsInstalled. Examining it revealed where the controller name install with a lower case "i" came from. I fixed the case there, recompiled and ran the application.

I now had the nopCommerce Installation Page.