FERDY CHRISTANT - JUL 27, 2015 (08:52:41 PM)
Although the whole world has gone mobile, when at home I tend to prefer work and play in my home office, which consists of a powerful desktop (Alienware Aurora R4) and 2 large 27" screens at 2560 x 1440. I've been enjoying this setup since 2012 on a daily basic, trouble free.
However, the system still has a conventional HDD, and upgrading to a SDD drive for long has been on my list of things to do. For about 2 years actually :) Anyway, as I increasingly found the disk to be the slowest part of the system, I finally had an incentive to do something about it. So last weekend I took the plunge, this post simply lists some of my experiences.
I wanted to feel the SSD performance upgrade across the board, so I went for a no-compromise solution: a 1TB SSD, the Samsung 850 EVO. Yes, having your OS on the SSD in itself is a vast improvement, however, I do very heavy photo editing (36MP photos) and work a lot with virtual machines. If those 2 tasks would still be done on a normal HDD, the upgrade would be far less of an upgrade overall. That said, since I would still have my conventional 2TB HDD, I will reconfigure that to be secondary drive, for even more storage.
Finally, there's an additional goal. My Aurora R4 shipped with a built-in copy of Windows 8. However, it is not shipped as a disk, nor is there a product key sticker anywhere. It is part of the BIOS or part of the recovery partition, I'm still not sure which.
Anyway, I want to keep that genuine Windows copy as part of the upgrade. It will help me transition to Windows 10 in a smoother way. Furthermore, the particular install of Windows 8 comes with Alienware utilities and drivers which are convenient to keep.
I've pondered over how to approach this upgrade. At first, I figured to just clone my entire current HDD. This way, the upgrade would be seamless. However, as my current Windows install is over 2 years old and goes well over 1TB, I ultimately decided to do a clean install (after first backing up everything onto my NAS).
A clean install of the factory setup, that is. I burned restore discs from Alien Autopsy, as the option to restore from the restore partition failed, I'm still not sure why. Using the discs worked. However, I then had several hours of Windows updates to install, both from Windows 8 and Windows 8.1.
With everything backed up and a clean, genuine install on the HDD, I figured the transition would be simple. Here's what I had in mind:
- Physically install SSD (in slot 2, slot 1 being used by the normal HDD)
- Check in BIOS if SSD is recognized, boot to Windows
- In Windows, clone the HDD to the SSD (using Samsung's data migration software)
- Reboot, and in the BIOS change the boot order to boot to the SSD
- Enjoy new SSD as if nothing happened
- Format normal HDD and use as 2nd drive
Simple enough. Except for the fact that every single step in that plan failed, and then some more. I spent close to a day chasing solutions to problems only to arrive at even more problems. It was such a large series of failures that I cannot even retrace all steps, but here's a few things I experienced:
- The SSD not being recognized in the BIOS. A BIOS update to V11 did not fix this either
- The Samsung software not recognizing the SSD at all, yet suddenly detecting it after a reboot
- The BIOS not recognizing my normal drive anymore either
- The clone method cloning to a non-C drive
- My entire system crashing when using AHCI mode (which is recommended for SSDs)
- The system booting to Windows with the SSD as secondary drive (which is not what I want)
- The system booting to Windows with the SSD as primary drive, yet with the wrong drive letter, screwing up the entire Windows install
The list is far longer than that, but I'll stop here. It did not go smooth, suffice to say.
It was very hard to find the problem, since everybody has a slightly different setup, goals and situation, yet I ultimately found it: it was a faulty cage.
The Alienware Aurora R4 has 3.5" inch hard drive slots. Since this SSD is 2.5", you need to buy a convertor "cage". It simply is a plastic box with inside it a connector. You insert your SSD in the cage into the connector, next you insert the cage as a whole into the HDD slot inside the desktop.
Actually, whether you need this cage or not depends on your exact model. The Alienware Aurora ALX models do need the cage, yet in the Aurora (non-ALX) R4 models, you don't strictly need them. It helps to better align the SSD, but it is not strictly needed, since the connectors are in the front, within reach.
Anyway, based on some Youtube install video I bought myself a Icydock cage. And this eventually turned out to be my mistake. My cage was faulty. Based on online research, it turns out I'm not the only one.
I removed the cage and instead decided to directly connect my SSD to the connectors. And bang, all my problems dissapeared:
- The SSD is now detected in the BIOS
- After booting to Windows on my normal HDD, cloning this time made a clone from C: to C:
- Reboot and change the boot order
- There it is: genuine Windows on C:, using the SSD
8 hours of agony ended in 10 minutes after making the direct connection. With this painful experience behind me, here are some recommendations:
- Investigate whether you need a cage at all, and if you buy one, buy a good one
- If your SSD is not recognized in the BIOS, do not proceed. Check the hardware, update the BIOS, do whatever is required to make that SSD appear in the BIOS
- When cloning, clone from C: to C:. If the data migration tool suggests a different target drive letter and doesn't let you pick C:, something is wrong. Do not proceed.
Help for such very specific scenarios is limited online, so if this helps only one person, I'm happy. You should be enjoying your SSD, instead of wasting your time on these issues.
Enjoying the SSD
Let's end with the good part, actually enjoying the SSD :)
I've only had a day of experience with it so far, but here's some results:
As expected, Windows boots a lot faster. What matters to me most is what happens after signing in to Windows. Normally, it appears to be ready, yet in reality it is still not responsive for 2 minutes or so. That delay is almost entirely gone. A few seconds after signing in, I have a browser open and ready to use.
That's awesome. And this snappy experience carries through all of my actions. Despite using a powerful desktop, I still always had the feeling that I was waiting for it, even for small actions. That friction is now gone. Things happen instantly.
What about photography? As a test, I did a fresh import of 300 RAW photos (45-60MB 36MP files) into Lightroom. I'd normally do such a thing when returning from the field. I'd also pour myself a drink in the meanwhile, as it takes a few minutes. With the SSD, it took mere seconds. I didn't time it, because I didn't expect it to be this fast. I thought something was wrong when it finished in front of my eyes. That's how fast it is.
The other big thing I do is to work with a Linux VM, my main development instance. Normally, I may have a small code change in mind, yet will postpone it, because powering on the VM, my IDE, build tasks and all takes too long. It's too costly to bother for a small change.
Not anymore. This entire LAMP stack is powered on in less than 2 seconds, and shutdown in the same amount of time. All friction is removed, and with it, all my excuses.
I'd like to end with that conclusion: this upgrade isn't just a hardware upgrade. It changes the way I compute at a fundamental level. As of now, friction is removed and the system is waiting for me, instead of me waiting for the system. I know I'm late to the SSD party, but better late than never :)
FERDY CHRISTANT - JUL 23, 2015 (11:03:34 PM)
It's been almost 2 months since I first announced my side project named Calumma. Despite the radio silence, I've been steadily progressing at it. This update is one of many to come.
First, a step back to summarize what the project is about: With project Calumma, I'm trying to kill two birds with one stone. By experimenting with new web technology, frameworks and more, I will further strengthen my web skills, which is my bread and butter. At the same time, I will do so in a way that will also benefit JungleDragon. If project Calumma succeeds, I will learn lots of new stuff whilst also designing solutions for the next version of JungleDragon. It's simply an efficient use of my time.
A rough outline of the steps and goals of this project would be:
- Set up a development workflow
- Create a new web front-end architecture:
- Test pages and demonstration for the front-end framework
- Design pages: concept designs for JungleDragon V5 based on the new front-end framework
The steps are not entirely sequential. As I learn new stuff along the way, I may go back and improve previous steps.
Anyway, it's time for the first post. The first several posts, even the majority of them, will all be about web development. If you're into that, it will be like looking over my shoulder as I learn new things and explain what worked and what didn't. I will also openly share solutions and things that may help you. I hope you find that interesting.
The topic of the first post is the development environment. It's not a terribly exciting topic, but we have to start somewhere, so let's go.
Calumma is pretty much a static, stand-alone project where I'm the only developer. I have placed it on my LAMP server which runs on a VM, but it could have been local development, as I will not be using a lot of PHP for this one, it's a front-end project mostly.
As a note to myself, longer term I want to try out Vagrant, which promises a very portable development setup. Or, I may finally launch my first Amazon EC2 instance. There is a free tier available, and after that reserved instances (where you pay upfront instead of per hour) look quite affordable.
You see, one of the key points of this project is to try out new things. Regarding development, I think cloud-based development is the future.
There's not much to tell about my folder setup, yet here it is:
It follows a pretty classic web project structure. A key point is that there is a SRC directory and an ASSETS directory. I do my editing in the SRC directory, and only there. A build process will "compile" the result into the assets directory, and only those files will actually be served.
Some web developers still have to get used to the idea of "building" a project, especially for a static project like this. Believe me though, once you are comfortable with some of the tools, you will experience the advantage of doing so, and never look back. Let's discuss some of those tools.
I'm already quite comfortable with SASS, and had no reason to change my CSS approach for this project. So what I do is that I edit SCSS files in the SRC/SCSS directory, and then an automatic watch process detects the change, compiles it into CSS, and live reloads my browser. All the power of SASS combined with the convenience of quick direct CSS authoring, it works for me.
There is a recent trend towards post-processing of CSS instead of pre-processing it, but it hasn't convinced me yet to switch.
One of the things I had on my list of things to learn is Bower. It's quite popular. Basically, it easily allows you to install a 3rd party dependency, for example jQuery. You can do so using a single command, and Bower will figure out where to download it, and install it in a special directory in your project. You can also easily update your dependencies with a single command.
I have given Bower a try, but it does not work for me. The thing is, Bower only installs things. Next, it is still up to you to figure out how to include those installed things in your project. But wait, there's build plugins to help with that! I tried those as well, and had very mixed results. For example, I installed an icon font using Bower, but could not automatically include it on my page, because the package definition did not support a required attribute needed for my build plugin. So now I have installed a plugin to support a tool which fails due to an incompatible package.
At this point, you start to wonder: why the hell am I going through this pain again? Just so that I do not have to go to a website, download some code and place it in my project? The tool that supposedly automates this is not taking away this "pain", it only adds more headaches.
Or so it did for me. I may work for you if you need to manage dozens of dependencies, but in this case, Bower tries to solve a problem that actually isn't a problem, at least not in this context. So I dropped it. Lesson learned.
Another new thing I wanted to try was LiveReload, which is a web browser plugin that detects file changes, and will then automatically reload you open browser, Chrome in my case, where I have the extension installed. In addition to having the extension installed, you need to include it in your build process, which is based on Gulp in my case.
Another new experiment was to add auto prefixing to my development workflow. The idea is that you can write a single unprefixed CSS statement (for example border-radius), after which this plugin as part of the build process will automatically add required vendor prefixes (for example -moz-border-radius) to the CSS output. You can configure it, for example "last 2 browsers" and it will base the prefixing on that policy.
It works well, so I'm keeping it. It's easy to forget that it is running in the background though, you start to blindly rely on it, and in case it goes wrong, you may a hard time finding the problem. So far so good though, it makes my SCSS just a little more clean.
There's a few tasks part of the build process not explained yet, but the tool binding all this together is Gulp. Less than 3 months ago I wrote about it here, and I haven't looked back since. It's now a new default in any project as it just so damn easy and powerful. Here's my entire development workflow for this project:
A summary of what this does:
- The clean task clears the assets dir, since the build process will generate fresh files
- The styles task will look for changes in the SCSS dir, compiles it into CSS, autoprefixes it, sends it to the assets dir and then reloads my browser. Note that I'm not too concerned about minification and gzipping at this point in time.
- The scripts task looks for changes in my JS dir, next it will concatenate all JS files into a single main.js file, which is moved to the assets dir. Note that the concatenation has some order logic to it, since we want to have some files listed first, for example jQuery.
- The default task is what happens if you would simply type "gulp" in the command line in the main project directory, in this case it will process both the styles and scripts, but only after first running "clean".
- I never run the default task though. What I do is to start the watch task. It does the same thing as the default task, yet it does it continuously, in the background.
That's it. To start a development session, I run "gulp watch", and without a care in the world I author the SCSS and JS that I need. It's a simple, yet effective development workflow.
This concludes the part about the development setup. My main takeaways are that Gulp is still awesome, Bower isn't for me, and LiveReload and Auto prefixing are useful additions to my belt of tools. In the next post, we'll move beyond the development setup and make a start with discussing the front-end framework.
Quick check: do you enjoy behind-the-scenes posts like these?
FERDY CHRISTANT - JUL 5, 2015 (08:39:15 AM)
Each year Henriette and I try to travel to a remote country to experience and photograph wildlife. By tradition, I never share such photos at once in a giant set, instead I share them slowly, a few each day, at JungleDragon.
I share them so slowly because that way I describe them very well, but also because these photos are my "winter stock" to keep sharing on JungleDragon when I am not out there photographing.
Anyways, hereby the Sri Lanka set is complete:
Some general links regarding Sri Lanka on JungleDragon:
Finally, for the interested some sets from previous travels:
May the tradition continue :)
FERDY CHRISTANT - MAY 30, 2015 (09:42:35 PM)
Hereby I am announcing a new side project, code-named "Calumma", after the chameleon genus. It is a vaguely defined project of an uncertain length and outcome, yet I still want to share its existence with you.
Project Calumma combines two goals that I am constantly after:
- To improve myself as a web developer
- To improve JungleDragon
Let's go into those goals a bit deeper...
Web development, with an emphasis on front-end engineering, has been one of my passions for a long time. But it's more than that, it's also my bread. I earn a living with it. As the world of front-end engineering is facing one technological revolution after the other, I must keep up.
The way I keep up, other than working on challenging projects at work, is to devote spare time on experimenting with new technology. Therefore, in this new side project, I will freely experiment with such technologies. I will specifically focus on development workflows, frameworks and new design techniques.
This part of the project is all about learning and personal development in my field. However, I intend to do it in a way that will also benefit JungleDragon, as well as anybody reading this blog with a technical interest.
This is the part where I am trying to kill two birds with one stone. From JungleDragon V2 until V4 right now, the platform has seen an avalanche of new features. Although there is always more to wish for, I believe we have arrived at a state where we have the major parts in place.
I am happy with the result. I think it is a great site. It works quite well, is fast, has a good usability (despite a few small flaws), and looks good. I am proud of it.
Yet pride should never get in the way of further improvement. The idea I have for project Calumma is to take the learnings from experimenting with new ways (phase 1), to see if I can raise the bar for JungleDragon from good to world-class.
There are definitely things in JungleDragon that I would have coded differently, as well as designed differently in hindsight. With project Calumma, I will freely experiment with technology and design to see what is possible.
In order to not be constrained by current choices, all of this will be developed completely separate from JungleDragon V4. JungleDragon V4 for now is going nowhere. I will obviously keep running it, managing the community, running contests and fixing bugs. Meanwhile, however, I am researching the next-gen JungleDragon in project Calumma.
The reason why I combine these two goals is because it maximizes both the efficient use of my time, as well as the output of that time, which will benefit both me and JungleDragon. Two birds, one stone.
What this will actually mean for JungleDragon is uncertain. It may mean nothing. It may mean small tweaks to current JungleDragon, it may mean JungleDragon V5. All of this depends on phase 1. The project is in a too early phase to tell.The plan
Although some vagueness still surrounds the project, I do have a plan in place. It may be subject to change, but here's the outline of some of the steps I have in mind:
Recently I have been experimenting with optimizing the development workflow, using tools like gulp, bower, and more. I will further invest time in learning these tools, as it will benefit both my personal development as well as my productivity. Better tools means better output.
In project Calumma, I am piecing many best practices together to arrive at a robust and powerful front-end framework. This consists of many components, for example for layout, responsive design, typography, feature detection, the list goes on and on.
This is a crucial phase of the project, as it will the base to build anything on. I will tune this framework to the point where it is very robust and flexible.
Why? If I have an ultra powerful front-end framework, I can build almost anything. The time from idea to execution becomes shorter, and its implementation more reliable and consistent. This phase of the project will take a lot of time, and lies at the core of both my learning goal and my JungleDragon goal.
To test my front-end framework, I will have a series of test pages, which showcase and test specific aspects of the framework. For example, there will be a page to test the grid, the typography, etc. In addition, there will be a styleguide showing all common styles and UI components in the framework.
After all of the previous steps, I'm going to put both my learnings and new framework to the real test. In this step I will design some crucial JungleDragon pages from scratch, such as the homepage, species page, country page, etc. This will not be on the live site, they will be static pages, using sample content.
As said, the goal is to go from good to world-class, so this one challenges both my skills and my framework. If I find the framework to be lacking, I will go back to the previous step. If I find my skills to be lacking, I will focus on learning.
That, in a nutshell, is the goal of Calumma: to challenge myself as well as JungleDragon's current design.
In this last phase of the project, I'm going to decide what to do with the results of the previous steps, and draw some conclusions. They are yet unknown. It could mean all of it was simply a good learning exercise. Or, it could mean the newly designed pages are so awesome that JungleDragon V4's front-end will be redesigned. Or anything in between those conclusions. I will obviously involve the community in getting feedback.
Work on Calumma has already started, and I am progressing quite well. I am working on multiple steps in parallel. I have a basic development workflow going, I have a base version of my framework (which still needs lots of work). I also have some test pages in place, and am currently working on the styleguide. The coming weeks I expect to be absorbed by these 3 steps. They require a hefty investment in time.
As for further timing, I don't have any hard targets, other than as fast as possible within my time constraints. This is a research project with an uncertain outcome and timing. It needs time for exploration, creativity, learning and quality. It very much is a long term engagement.
I'm sorry if the above sounds vague or too technical. This is only the first announcement, things will become more clear as I progress in this ambitious new side project. I am quite excited about it :)
FERDY CHRISTANT - MAY 15, 2015 (10:40:51 AM)
JungleDragon update 23 of V4 is now live. This update brings a few small improvements at species records. We'll be using the "Red fox" species page to show the improvements:
The improvements are in the right column. First, the distribution map:
This image is automatically parsed from the corresponding Wikipedia page for the species. Not all species records have them. Usually, such an image is aided by a legend text below it. Occassionally JungleDragon has trouble in accurately parsing that legend text from the Wikipedia page, as it can come in many formats. Therefore, if there's any issue or weird characters in the legend text, it can now directly be edited by moderators on the species edit form:
A small but welcome improvement. Before, I had to directly hack this in the database, without any user interface. Up next is the taxonomy block;
The change here is that the values are now links, where before they were just text. In a way, they are the same links as shown in the breadcrumb. Here's what happens when clicking "Canidae":
All canids directly in the species browser. Nice.
The next block is the "Photographed in" block:
This lists the countries in which this particular species was photographed. Before, when clicking such a country, it would take you to the species tab of that country, showing all species of the country. A nice starting point, but maybe not what you expect. This is now changed, when clicking the country in this list, it will show you all photos of that species in that country. Here's all photos of the Red Fox taken in the Netherlands:
Finally, on the moderator panel, both total lists of species are now divided across pages. Instead of loading thousands, it now loads 240 per page.
That's it, hope you like these improvements.