The world has significantly changed after smartphones has been released, especially after the first iPhone. Therefore mobile applications became popular very quickly. Since I own an iPhone, I was excited how people around the world got fascinated for mobile applications, also known as apps. The more frustrating it is as a web developer, not being able to write own mobile apps in a native way.
The ‘Command and Query Responsibility Segregation’ (CQRS) design pattern is based on the “Command-Query Separation” (CQS) principle from the book “Object-Oriented Software Construction“ by Bertrand Meyer (1988) and was first mentioned by Greg Young and Udi Dahan in 2010.
This pattern has produced a lot of excitement and hype but the principle behind it is very simple.
As the demands on command methods (any method with write access that mutates state) are usually very different to those on query methods (any method with read access that returns a value), it makes sense to separate these two groups. This would naturally mean different services but might also mean different models.
Many web application developers have tried to develop a high performance web application with real-time behaviors. A common example of such an application could be a communication web platform like a chat application. A message sent by a user should be transmitted in real-time to other users.
Years ago I tried to develop a chat web application but until now it has not been so easy to achieve. I would like to show you how easily and clearly it can be implemented today.
There will be a comparison of the different approaches to develop a real-time web application which will show that it has never been easier to achieve it before.
The approaches I want to compare are the “new” WebSocket technology and the “old” Comet approach. First you will see how difficult it was and how easy it is today to write a small communication platform. You will also get the easy and clear source code of the communication platform through the WebSocket technology. This article does not cover a complete WebSocket description but a short insight of the WebSocket technology advantages and a practical usage.
“Under the Hood” blog series – getting a deeper technical insight like the mobile solutions, JVM, computer languages, scripts, databases and other interesting tools and technologies. Each blog in this series is a result from our experiences, customer projects and gained knowledge through the web community.
It is the Android Software that Counts, Stupid!
Are you planning to purchase an Android smartphone? Do you feel overwhelmed by the sheer amount of devices? You don’t want a new smartphone but your device is outdated? There is this specific app you want to install and requires a new Android Operating System version?
Would it not be nice to have something similar like botox for your wrinkles but for your old device? Well, there is. It is called “mod” and requires hacking instead of injecting.
This blog will not help you in deciding which hardware or manufacturer fits you better. Instead I can provide some clarifications about the various Android derivatives.
It explains how files are split into blocks and how the filesystem acts as an abstraction layer between files (seen by applications) and blocks (physically written on disks). It also says why disks are called block devices.
1.1 Splitting Up Files Into Blocks
A block device is a storage media, like a hard disk. You can use ‘blkid’ and ‘fdisk -l’ to show a list of block devices attached to your system.
In the following example, ‘sda’ is a disk with 2 partitions ‘sda1′ and ‘sda2′, and ‘sr0′ is a compact disc.
A filesystem can be created on a partition and also on a whole partitionless disk, as both partition and disk are valid block devices.
/dev/sda1: UUID="5b0e4487-b5aa-4186-81fd-f561308f4cf1" TYPE="swap"
/dev/sda2: UUID="ec851750-9854-4227-8898-d5695dbd297e" TYPE="ext3"
/dev/sr0: LABEL="VBOXADDITIONS_4.2.16_86992" TYPE="iso9660"
Disk /dev/sda: 12.9 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders, total 25165824 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000be060
Device Boot Start End Blocks Id System
/dev/sda1 2048 786431 392192 82 Linux swap / Solaris
/dev/sda2 * 786432 25165823 12189696 83 Linux
In order to use the hardware efficiently and to increase the addressing limit the disk read and write operations are not processing the data byte by byte. Instead these operations are using a larger unit called a block (also called a sector), which is usually 512 Bytes.
This blog series aims to be a reference guideline by collecting useful knowledge and tutorials about Linux filesystems, mainly about ext3 and ext4.
Because, as systems engineers/administrators, when we need to manually perform disk maintenance on a server, we know that a tiny mistake may have large consequences.
“Trial-and-Error” is sometimes a good way to learn, and sometimes not. For sensitive topics like internet security or filesystem operations, it is often better to understand the theory based on reliable sources before trying; in this way we can avoid putting the data integrity at unnecessary risk.