Just got my hands on this nifty little device. I LOVE it.
Apparently the phone is selling well. Although Nokia has released no numbers on the total of Phones produced, or any numbers on how many actually have been sold yet. It is what it was meant for : a phone for geeks.
So what do you need in order to develop on a N9? On Windows, QTCreator is the best choice. Make sure you install the HARMATTAN (funny how Nokia wants users know that it is highly "experimental") extensions. That's it. This will give you a perfect RAD environment to develop apps out of the pocket in a fast and straightforward way.
On Linux, you can do the same and install QtCreator. Or, in case you feel confident enough in jiggling the penguin, you can do it the proper way and go for the Scratchbox (for those versions that actually support it):
http://harmattan-dev.nokia.com/unstable/beta2/harmattan-sdk-setup.py
This will give you a total freedom; price is infinite complexity.
Typicall steps, in this case, include:
a) Locating sources of components that your application might depend upon and will be missing from the standard Harmattan repo (located in http://harmattan-dev.nokia.com/pool btw)
b) Building the components
c) Build your code against them
d) Create a package : dpkg-buildpackage -D
Sunday, October 23, 2011
Monday, March 15, 2010
Some more thinking part 3 - or, the really I need to write it down thread!
So!
We were discussing items like code which can be written by machines and such (in the last post). Note : this may necessarily not be true, it may be just a kick to get you linked to this page...Jokes apart. A machine can't know the code it will execute before it executes it, right? Or, better said, a machine can't know any code before it analyzes it. But, of course, we are talking about problem-solving in here, so why the heck would a program need to analyze a software (which actually handles the problem-solving by itself) to solve a specific problem? Back at you : how does the software know it solves the specific problem anyway? The answer is as simple and clear as you can (as most of the time you get it in Software engineering) get : it doesn't.
So what can you make out of it?
Consider : you have a machine, then you have a piece of code, which the machine has never executed before. How can the machine know what that same piece of code does, if not by executing it? Whilst the concept of virtualization comes to mind, that might not be a feasible solution to the problem, considering all the side-costs it brings with it; for an example, anti-virus software share the same type of issue, but address it at a higher level, by analyzing codebyte-patterns. A virtual machine would be way to costy.
On the other hand, even if a machine would analyze some code, it would still need to execute it (even if in a protected / virtual environment) to understand the effects of every single instruction.
It seems the answer is simple : there is no way for a machine to completely know what a source code does without executing it.
We were discussing items like code which can be written by machines and such (in the last post). Note : this may necessarily not be true, it may be just a kick to get you linked to this page...Jokes apart. A machine can't know the code it will execute before it executes it, right? Or, better said, a machine can't know any code before it analyzes it. But, of course, we are talking about problem-solving in here, so why the heck would a program need to analyze a software (which actually handles the problem-solving by itself) to solve a specific problem? Back at you : how does the software know it solves the specific problem anyway? The answer is as simple and clear as you can (as most of the time you get it in Software engineering) get : it doesn't.
So what can you make out of it?
Consider : you have a machine, then you have a piece of code, which the machine has never executed before. How can the machine know what that same piece of code does, if not by executing it? Whilst the concept of virtualization comes to mind, that might not be a feasible solution to the problem, considering all the side-costs it brings with it; for an example, anti-virus software share the same type of issue, but address it at a higher level, by analyzing codebyte-patterns. A virtual machine would be way to costy.
On the other hand, even if a machine would analyze some code, it would still need to execute it (even if in a protected / virtual environment) to understand the effects of every single instruction.
It seems the answer is simple : there is no way for a machine to completely know what a source code does without executing it.
Tuesday, March 9, 2010
ESXi and Cron
Many people say ESXi doesn't come with cron.
Well, that is not necessarily the case.
A cron table for the user root is located under /var/spool/cron/crontabs/root.
The way to do it is the dirty way : through vi.
NOTE : Most likely, this crontab is automatically deleted on shutdown.
This has not been tested, but it is likely to work. IF somebody manages to test it, please let me know.
You probably want to keep a copy of it in the /bootbank/oem.tgz archive. Note also that the OEM tgz gets decompressed at root level, which means you also have to compress the full path to your files. Decompress the archive to a temporary directory (say, /tmp/oemarch/), create the same directory path (/var/spool/cron/crontabs) under this temp dir and copy the crontab ("root") from the /var/spool/cron/crontabs location to this new temp folder. Recompress everything and replace the old oem.tgz archive with this new one.
Well, that is not necessarily the case.
A cron table for the user root is located under /var/spool/cron/crontabs/root.
The way to do it is the dirty way : through vi.
NOTE : Most likely, this crontab is automatically deleted on shutdown.
This has not been tested, but it is likely to work. IF somebody manages to test it, please let me know.
You probably want to keep a copy of it in the /bootbank/oem.tgz archive. Note also that the OEM tgz gets decompressed at root level, which means you also have to compress the full path to your files. Decompress the archive to a temporary directory (say, /tmp/oemarch/), create the same directory path (/var/spool/cron/crontabs) under this temp dir and copy the crontab ("root") from the /var/spool/cron/crontabs location to this new temp folder. Recompress everything and replace the old oem.tgz archive with this new one.
Monday, January 25, 2010
Cruisecontrol and default contexts
Any programmer knows about Cruisecontrol and more in general about the concepts of Continuous Integration. Or at least they should.
The latest release of Cruisecontrol opens up the Jetty configuration completely, which is awesome, since you get a free complete webserver with it, which can handle publushing of files on HTTP. Awesome.
There are some issues, sure. Like for an example the standard Cruisecontrol deployment (binary form) doesn't define any default contexts in the jetty configuration. Which means once you start Cruisecontr0l, you won't have a default homepage setup (by default).
Well, there is an easy fix for that.
First, in the Cruisecontrol home (for example C:\cruisecontrol) create a directory "contexts".
Second, follow this snippet (just highlight & copy):
Restart your Cruisecontrol, open up a webbrowser and navigate to http://localhost:80 and voilá.
The latest release of Cruisecontrol opens up the Jetty configuration completely, which is awesome, since you get a free complete webserver with it, which can handle publushing of files on HTTP. Awesome.
There are some issues, sure. Like for an example the standard Cruisecontrol deployment (binary form) doesn't define any default contexts in the jetty configuration. Which means once you start Cruisecontr0l, you won't have a default homepage setup (by default).
Well, there is an easy fix for that.
First, in the Cruisecontrol home (for example C:\cruisecontrol) create a directory "contexts".
Second, follow this snippet (just highlight & copy):
<?xml version="1.0"
encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
<Set name="contextPath"><Property name="foo"/></Set>
<Set name="war"><SystemProperty name="jetty.home" default="."/>/webapps/test</Set>
</Configure>
Restart your Cruisecontrol, open up a webbrowser and navigate to http://localhost:80 and voilá.
Tuesday, September 22, 2009
Some more thinking about the three concepts of programming
Consider the last of the three principles of programming:
Now, without diving into the details of testing - how much of this process can we automate without writing any additional code?
Consider this situation : the perfect solution would be the machine itself knows what she has to test out of the box. That would mean the machine knows the behaviour of our software artifact already before it would had been written (possibly), which in turn would get you to think that hey, the machine could write that piece of functionality by itself! if it already knows the nature of the functionality, correct?
This already sounds hidious, doesn't it? You realize where it is heading, or? Exactly, it tastes alot like the good old "dog biting tail" paradox.
Endurance recalls the fact that coding is not only "pressing a button to compile", but also making sure that thet code you have been writing works as it is supposed to.Debugging is a tedious process. Basically, it consists in checking the functionality that has been added within the coding phase. The (stupid) machine is not able to go through it by itself AND at the same time evaluate the correctness of it. Sure enough, the activity can be automated through some testing code, but that again translates in (as the name says) more coding.
Now, without diving into the details of testing - how much of this process can we automate without writing any additional code?
Consider this situation : the perfect solution would be the machine itself knows what she has to test out of the box. That would mean the machine knows the behaviour of our software artifact already before it would had been written (possibly), which in turn would get you to think that hey, the machine could write that piece of functionality by itself! if it already knows the nature of the functionality, correct?
This already sounds hidious, doesn't it? You realize where it is heading, or? Exactly, it tastes alot like the good old "dog biting tail" paradox.
...and there came the day the Linux stood still.
Damn you Linux!
And it gets worser..
Damn you Ubuntu!
Half a day lost - for what? Don't know. I know what happened. A machine running Ubuntu 64 bit Server (that had worked fine for over 8 months) suddently stopped booting into gdm.
On login to any user, it woulds state "/dev/null no permissions". WTF?
See, this is exactly why linux (written with a lower case L on purpose, didn't deserve the capital one today!) sucks. When something goes wrong - it NEVER does, really, but when it happens - its almost a total disaster. Mainly for two reasons.
So what happened? Apparently, some "obscure" thing mixed up the /lib/lbs/init-functions file, which ended up being empty. This in turn caused the (all) services to exit with log_daemon_msg messages, causing services who invoked them to think they failed.
Which translates in a clean boot in the most proper way, as in no services started. Not even ifconfig for configuring the network interfaces for an example.
Well, luckily that "obscure" thing was kind enough to take a backup of the init-functions before erasing the contents. Which btw excludes Hard Disk crashes (and shuts the mouth to all of you I-know-better out there) who are not even as half as nice to make a backup before taking action.
Once restored, the system seems to work fine (so far).
But what caused that problem? No one knows, not even Google....
And it gets worser..
Damn you Ubuntu!
Half a day lost - for what? Don't know. I know what happened. A machine running Ubuntu 64 bit Server (that had worked fine for over 8 months) suddently stopped booting into gdm.
On login to any user, it woulds state "/dev/null no permissions". WTF?
See, this is exactly why linux (written with a lower case L on purpose, didn't deserve the capital one today!) sucks. When something goes wrong - it NEVER does, really, but when it happens - its almost a total disaster. Mainly for two reasons.
- The system usually is totally or partially unusable
- Finding out what happened takes half a time of your life
- 20 years of development and noone cared doing a proper, centralized log viewer interface - you know what, f*ck you.
So what happened? Apparently, some "obscure" thing mixed up the /lib/lbs/init-functions file, which ended up being empty. This in turn caused the (all) services to exit with log_daemon_msg messages, causing services who invoked them to think they failed.
Which translates in a clean boot in the most proper way, as in no services started. Not even ifconfig for configuring the network interfaces for an example.
Well, luckily that "obscure" thing was kind enough to take a backup of the init-functions before erasing the contents. Which btw excludes Hard Disk crashes (and shuts the mouth to all of you I-know-better out there) who are not even as half as nice to make a backup before taking action.
Once restored, the system seems to work fine (so far).
But what caused that problem? No one knows, not even Google....
Monday, September 7, 2009
Three basic foundation principles of programming
Making software (aka "programming") comprises itself of three separate principles:
a) Writing
b) Logic
c) Endurance
Writing is specifically important from the understandability point of view. Complicated code written in a complicated way doesn't really help the reader to understand it better.
Logic is, well, the basics of informatics in general, your morning star. Whichever problem you want to solve, logic is the way to do it (and mathematics).
Endurance recalls the fact that coding is not only "pressing a button to compile", but also making sure that thet code you have been writing works as it is supposed to.
This last part is usually also called "debugging".
a) Writing
b) Logic
c) Endurance
Writing is specifically important from the understandability point of view. Complicated code written in a complicated way doesn't really help the reader to understand it better.
Logic is, well, the basics of informatics in general, your morning star. Whichever problem you want to solve, logic is the way to do it (and mathematics).
Endurance recalls the fact that coding is not only "pressing a button to compile", but also making sure that thet code you have been writing works as it is supposed to.
This last part is usually also called "debugging".
Subscribe to:
Posts (Atom)