Friday, December 19, 2014
Scala Maven Project including Specs2
Since I found no up-to-date Maven Project for Scala that includes everything I want (especially Specs2), I created my own one on GitHub. There's a problem with some versions of Specs2, because org.scalaz.stream cannot be found. Due to that issue, the project currenty uses Specs 2.4 (for Scala 2.11).
Labels:
Maven,
org.scalaz.stream,
Scala,
Scala 2.11,
Specs 2
Tuesday, December 16, 2014
Updating Adobe Flash Plugin on Debian Wheezy
After my Iceweasel (Firefox) was telling me several times that the Adobe Flash Plugin is vulnerable and needs to be updated (Chromium wasn't complaining at all), I was wondering why no update is being installed when running APT?
Fortunately, the Debian Wiki explains how to update the Adobe Flash Plugin:
~# update-flashplugin-nonfree --install
Fortunately, the Debian Wiki explains how to update the Adobe Flash Plugin:
~# update-flashplugin-nonfree --install
Labels:
Adobe Flash Plugin,
Debian,
Iceweasel,
Update,
Vulnerable
Thursday, December 11, 2014
Published 'admintools' on GitHub
Some helpful scripts for system administrators are now available on GitHub.
Wednesday, December 3, 2014
IMAP over SSLv2 - Evolution Mail does not work on Debian 7.7 Wheezy: Enable TLS over port 993
After my email provider disabled SSLv3 for IMAP due to that security problem known as Poodle, Evolution Mail 3.4.4 on my Debian 7.7 Wheezy stopped working. Since there's no "ready-to-install" patch available yet, I rolled my own solution. [1] describes a patch that needs to be applied to the evolution-data-server and therefore we need to build evolution-data-server from the sources available through APT. In [2] there's a step-by-step howto, that explains how to build a APT package. I augmented those steps with the steps that were missing to build a patched evolution-data-server.
[1] evolution-data-server-3.10.4-poodle-enable-tls-for-ssl.patch for bug #1153052
[2] Re: [Evolution] my Evolution 3.6.2 backport to Ubuntu 10.12
- su -
- create a new directory and cd into it
- apt-get build-dep evolution-data-server
- apt-get source evolution-data-server
- cd evolution-data-server-3.4.4
- apply patch as described in [1]
- dpkg-source --commit (e.g. "Enable TLS over port 993)
- maybe: install fakeroot and dpkg-dev
- apt-get install fakeroot
- apt-get install dpkg-dev
- dpkg-buildpackage -rfakeroot
- cd ..
- dpkg -i *.deb
[1] evolution-data-server-3.10.4-poodle-enable-tls-for-ssl.patch for bug #1153052
[2] Re: [Evolution] my Evolution 3.6.2 backport to Ubuntu 10.12
Dynamic Packaging Prototype on GitHub
Something that I should have done in the past, but due to a lack of something that I consider "interesting" or worse to bore the world with it...at the end I never open sourced anything. But this will change now!
The first project that I gonna open source is an implementation of a distributed web-server written with Scala, Akka and Spray during my Master Thesis last year. The aim of the project was to implement a prototype for a "Dynamic Packaging" application, which is commonly used in the travel and tourism industry. I used the prototype mainly to do measurements and evaluate how Akka performs in terms of CPU utilization and horizontal scaling. I wouldn't necessarily recommend to use the project for "mission critical" things, but more as a source for ideas.
- Dynamic Packaging Prototype (server)
- Dynamic Packaging Prototype (client)
The first project that I gonna open source is an implementation of a distributed web-server written with Scala, Akka and Spray during my Master Thesis last year. The aim of the project was to implement a prototype for a "Dynamic Packaging" application, which is commonly used in the travel and tourism industry. I used the prototype mainly to do measurements and evaluate how Akka performs in terms of CPU utilization and horizontal scaling. I wouldn't necessarily recommend to use the project for "mission critical" things, but more as a source for ideas.
- Dynamic Packaging Prototype (server)
- Dynamic Packaging Prototype (client)
Labels:
Akka,
Cluster,
Distributed,
Dynamic Packaging,
Scala,
Webserver
Sunday, April 13, 2014
Dynamic and Static Typing
It happened to me more than once, that I heard people talking about something referred to as "scripting languages" and the fact that those kind of languages have no types. In this post, I want to clarify this subject in more detail. The term "scripting language" doesn't really exist in Computer Science. Therefore, two different type systems for programming languages do exist: compiled (static) and interpreted (dynamic). With static typed languages, the type checking takes place during compilation, whereas dynamic typed languages do the type checking at runtime, by the interpreter that executes the program. Popular representatives for statically typed (and compiled) languages are for example C++ and Java. Python, Perl and Ruby are languages which are dynamically typed and executed by an Interpreter.
But how is a software developer confronted with dynamic and static typing?
Example No.1 (Scala):
scala> var i = 42
i: Int = 42
Scala is a statically typed programming language, but sometimes it might look like its dynamically typed, because it allows the developer to write less boilerplate code. After assigning the integer value 42 to the variable i, the Scala compiler is able to recognize that i is of type Int, which is done through type inference. The compiler "guesses" the type of the variable by determining the type of the expression on the right hand side of the assignment.
Lets look what happens, if we try to assign a string to i:
scala> i = "Hello World!"
<console>:8: error: type mismatch;
found : String("Hello World!")
required: Int
i = "Hello World!"
Since the variable i is of type Int, we cannot assign it any value that is different from the type of integer - due to the fact of static typing. A special case is Polymorphism, where a "super-type", can hold values (references) of all "sub-types".
Example No.2 (Python):
>>> i = 42
>>> type(i)
<type 'int'>
In the second example, I did the same assignment as before, but using a dynamically typed programming language - in this case: Python. To invalidate the argument, that (scripting) languages like Python have no types, look at line three. Every variable in Python has a type, that can be determined at any given point in time during execution by using the type function.
Lets look what happens, if we try to assign a non-integer value to i:
>>> i = "Hello World!"
>>> type(i)
<type 'str'>
As we can see, the type of variable i has changed from integer to string. That is due to the fact, that Python is a dynamically typed programming language, where the type of a variable can change over time.
Both, dynamic and static typed programming languages have pros and cons. Dynamic typed languages are a good choice for rapid prototyping, because sometimes types stay in the way, when developers want to be creative and think about a solution for a problem. On the other side, since the absence of a compiler, the developer has to make sure that for example, a method that awaits an integer as argument, is not called given a string - which would lead most likely to a runtime exception, depending on the methods implementation.
Although, dynamically typed languages easy rapid prototyping, they are often slower than compiled languages. Furthermore, refactoring is more difficult when using dynamic typed languages, because syntax errors (wrong (text-)replacements) are not discovered by a compiler, but have to be found by self-written unit tests. Therefore, a really high test coverage of the whole source code is necessary.
References:
DynamicTyping
Type System
Type Systems for Programming Languages
But how is a software developer confronted with dynamic and static typing?
Example No.1 (Scala):
scala> var i = 42
i: Int = 42
Scala is a statically typed programming language, but sometimes it might look like its dynamically typed, because it allows the developer to write less boilerplate code. After assigning the integer value 42 to the variable i, the Scala compiler is able to recognize that i is of type Int, which is done through type inference. The compiler "guesses" the type of the variable by determining the type of the expression on the right hand side of the assignment.
Lets look what happens, if we try to assign a string to i:
scala> i = "Hello World!"
<console>:8: error: type mismatch;
found : String("Hello World!")
required: Int
i = "Hello World!"
Since the variable i is of type Int, we cannot assign it any value that is different from the type of integer - due to the fact of static typing. A special case is Polymorphism, where a "super-type", can hold values (references) of all "sub-types".
Example No.2 (Python):
>>> i = 42
>>> type(i)
<type 'int'>
In the second example, I did the same assignment as before, but using a dynamically typed programming language - in this case: Python. To invalidate the argument, that (scripting) languages like Python have no types, look at line three. Every variable in Python has a type, that can be determined at any given point in time during execution by using the type function.
Lets look what happens, if we try to assign a non-integer value to i:
>>> i = "Hello World!"
>>> type(i)
<type 'str'>
As we can see, the type of variable i has changed from integer to string. That is due to the fact, that Python is a dynamically typed programming language, where the type of a variable can change over time.
Both, dynamic and static typed programming languages have pros and cons. Dynamic typed languages are a good choice for rapid prototyping, because sometimes types stay in the way, when developers want to be creative and think about a solution for a problem. On the other side, since the absence of a compiler, the developer has to make sure that for example, a method that awaits an integer as argument, is not called given a string - which would lead most likely to a runtime exception, depending on the methods implementation.
Although, dynamically typed languages easy rapid prototyping, they are often slower than compiled languages. Furthermore, refactoring is more difficult when using dynamic typed languages, because syntax errors (wrong (text-)replacements) are not discovered by a compiler, but have to be found by self-written unit tests. Therefore, a really high test coverage of the whole source code is necessary.
References:
DynamicTyping
Type System
Type Systems for Programming Languages
Labels:
dynamic typing,
polymorphism,
Python,
Scala,
static typing,
type inference
Tuesday, April 1, 2014
Installing CouchApp on Debian as non-root
Installing CouchApp on my Debian machine was (after all) pretty much straight forward.
Dependencies needed by CouchApp:
- apt-get install setuptools
- apt-get install libyaml-dev
Check out latest sources from GitHub:
git clone https://github.com/couchapp/couchapp
...configure && make
cd couchapp
python setup.py install --user
For now, you're done!
References:
Building CouchApps
Installing Python Modules
Dependencies needed by CouchApp:
- apt-get install setuptools
- apt-get install libyaml-dev
Check out latest sources from GitHub:
git clone https://github.com/couchapp/couchapp
...configure && make
cd couchapp
python setup.py install --user
For now, you're done!
References:
Building CouchApps
Installing Python Modules
Wednesday, March 26, 2014
Execute Programs and Handle their Output with Python
One nice feature of Perl is how easy it is to execute external programs. Therefore, one can use the built-in qx() function ("quote execute"). For example:
my $output = qx(cat /var/log/messages | grep fail);
After the above line has been executed, the variable output holds all system messages that contain the substring "fail". To achieve an equivalent solution with Python prior to version 2.6, the popen() function of the os module could be used:
import os
f = os.popen('cat /var/log/messages | grep fail', 'r')
output = f.readlines()
f.close()
Or shorter:
output = os.popen('cat /var/log/messages | grep fail').readlines()
Since the above is marked as deprecated starting with Python 2.6, a less intuitionally solution has to be implemented by using the subprocess module.
import subprocess
cmd = 'cat /var/log/messages | grep fail'
f = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE).stdout
output = f.readlines()
f.close()
Or shorter:
output = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE).stdout.readlines()
Putting it all together, here's the qx() function written as a one-liner:
def qx(cmd):
return subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE).stdout.readlines()
IMPORTANT: Make sure that you don't execute any given string, but only those who you trust!
References:
http://docs.python.org/2/library/subprocess.html#subprocess-replacements
my $output = qx(cat /var/log/messages | grep fail);
After the above line has been executed, the variable output holds all system messages that contain the substring "fail". To achieve an equivalent solution with Python prior to version 2.6, the popen() function of the os module could be used:
import os
f = os.popen('cat /var/log/messages | grep fail', 'r')
output = f.readlines()
f.close()
Or shorter:
output = os.popen('cat /var/log/messages | grep fail').readlines()
Since the above is marked as deprecated starting with Python 2.6, a less intuitionally solution has to be implemented by using the subprocess module.
import subprocess
cmd = 'cat /var/log/messages | grep fail'
f = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE).stdout
output = f.readlines()
f.close()
Or shorter:
output = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE).stdout.readlines()
Putting it all together, here's the qx() function written as a one-liner:
def qx(cmd):
return subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE).stdout.readlines()
IMPORTANT: Make sure that you don't execute any given string, but only those who you trust!
References:
http://docs.python.org/2/library/subprocess.html#subprocess-replacements
Labels:
execute command,
execute program,
popen,
Python,
subprocess module
Subscribe to:
Posts (Atom)