Skip navigation

Category Archives: Eksplorasi


Just share a bit. When we want to commit source code, it’s better to check locally before pushing the source code to repository which then check them at the build server.

Here’s a source code for the wrapper script. The needed binaries are PHPCS, ESLint, and Stylelint.

To execute in the pre-commit, you can just use this.

SOURCE_FILES=${SOURCE_FILES:-`git diff-index --name-only --diff-filter=ACMR HEAD`}
export SOURCE_FILES
./checkstyle.sh

exit $?

This was just an idea popped up when I had trouble sleeping last night. Basically we can use Thrift for defining the data and service going in and out Lambda service instead of plain REST API.

Below is the code for the server. To make it easier to deploy I am using Serverless Framework.

This is still lack authentication process whatsoever so I don’t think this should be use in production until I figure it out.

The full source code is hosted here: https://github.com/petrabarus/aws-lambda-thrift-example


Putting this here too (I’m in habit for putting scripts into blog).


Just drop this again..

at first I’m using awk, but turns out there is pr command.

Source: Stackoverflow.


Just dropping by here


Usually before committing a file we need to check modified files against the code convention before committing to the code repository.

Here’s a single line to run modified files in Git against PHPCS.

git ls-files -m | grep '\.php$' | xargs ./vendor/bin/phpcs -s --standard=etc/phpcs/ruleset.xml

Code above assumes you install PHPCS using composer and have your own standard located in the etc/phpcs/ruleset.xml.

UPDATE

To check all uncommited files, run this

git ls-files --others --exclude-standard | grep '\.php$' | xargs ./vendor/bin/phpcs -s --standard=etc/phpcs/ruleset.xml

For quite some time I’ve been looking for a very easy way to deploy a small service using Java that is accessible through HTTP and self-hosted, or in other words, it doesn’t need a installed server. I was initially thinking about using embedded Tomcat or Jetty by writing the server code manually.

But then it turns out that there is this project from Spring built specifically for this kind of application: the Spring Boot. As quoted from the web,

Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that can you can “just run”.

By using this framework, I only need to focus on building the service rather than writing the HTTP server. And running the service is just as simple as using plain old `java -jar`.

The whole source code can be seen in this URL https://github.com/petrabarus/springboot-opsworks-example.

I started by using the sample code from Spring Boot.

import org.springframework.boot.*;
import org.springframework.boot.autoconfigure.*;
import org.springframework.stereotype.*;
import org.springframework.web.bind.annotation.*;

@Controller
@EnableAutoConfiguration
public class SampleController {

    @RequestMapping("/")
    @ResponseBody
    String home() {
        return "Hello World!";
    }

    public static void main(String[] args) throws Exception {
        SpringApplication.run(SampleController.class, args);
    }
}

The skeleton code for the controller can not be much simpler than this.

And here’s the POM file.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>net.petrabarus.maleskoding</groupId>
    <artifactId>springboot-opsworks-example</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>1.1.6.RELEASE</version>
    </parent>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <!-- Sets to use Jetty. No particular reasons -->
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-jetty</artifactId>
        </dependency>
        <dependency>
            <!-- For deployment ready -->
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
    </dependencies>
    <build>
        <resources>
            <resource>
                <!-- Creates directory for OpsWorks config -->
                <directory>src/deploy</directory>
                <targetPath>../deploy</targetPath>
            </resource>
            <resource>
                <!-- Creates config directory for external config --> 
                <directory>src/config</directory>
                <targetPath>../config</targetPath>
            </resource>
        </resources>
        <plugins>
            <plugin>
                <!-- Creates JAR -->
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
            <plugin>
                <!-- Creates zip distributable -->
                <artifactId>maven-assembly-plugin</artifactId>
                <version>2.4</version>
                <configuration>
                    <descriptor>src/assembly/dep.xml</descriptor>
                </configuration>
            </plugin>
        </plugins>
    </build>
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.compiler.source>1.7</maven.compiler.source>
        <maven.compiler.target>1.7</maven.compiler.target>
    </properties>
</project>

The XML code below is the minimum configuration to run the service. (The spring-boot-starter-jetty is used to make the service runs using Jetty instead of the default embedded Tomcat).

<!-- cut -->
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>1.1.6.RELEASE</version>
    </parent>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <!-- Sets to use Jetty. No particular reasons -->
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-jetty</artifactId>
        </dependency>

<!-- cut -->

To build the JAR, I use this plugin

<!-- cut -->
    <build>
        <!-- cut -->
        <plugins>
            <plugin>
                <!-- Creates JAR -->
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
<!-- cut -->

Building the JAR is simply just by executing

$mvn clean install

and the JAR will be in the `target` directory, e.g. target/springboot-opsworks-example-1.0-SNAPSHOT.jar I run it using the usual java -jar command

$target/springboot-opsworks-example-1.0-SNAPSHOT

I can see the result by using curl

$curl localhost:8080
Hello World!

Now it’s time to deploy it using OpsWorks. In this example I use `HTTP archive`, but it’s better to use `S3 archive` to provide better security since it can use IAM credentials.

Screenshot from 2014-09-20 00:02:21

The ZIP-ed file for deployment can be created using `spring-boot-maven-plugin`

<!-- cut -->
    <build>
        <!-- cut -->
        <plugins>
            <plugin>
                <!-- Creates zip distributable -->
                <artifactId>maven-assembly-plugin</artifactId>
                <version>2.4</version>
                <configuration>
                    <descriptor>src/assembly/dep.xml</descriptor>
                </configuration>
            </plugin>
<!-- cut -->

Here’s the assembly XML configuration

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2" 
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
    <id>bin</id>
    <formats>
        <format>zip</format>
    </formats>
    <fileSets>
        <fileSet>
            <directory>${project.build.directory}</directory>
            <outputDirectory>/</outputDirectory>
            <includes>
                <include>*.jar</include>
            </includes>
        </fileSet>
        <fileSet>
            <directory>${project.build.directory}/config</directory>
            <outputDirectory>config</outputDirectory>
            <includes>
                <include>*.xml</include>
                <include>*.properties</include>
                <include>*.yml</include>
            </includes>
        </fileSet>
        <fileSet>
            <directory>${project.build.directory}/deploy</directory>
            <outputDirectory>deploy</outputDirectory>
        </fileSet>
    </fileSets>
</assembly>

Now I can have a very simple build and distribution script like below. This can be use for Jenkins. When a new change is pushed to the git repository, Jenkins will download the change, build, test the source, and then pack and upload the binary.

$mvn clean install assembly:single && s3cmd put -P target/*.zip s3://path/to/the/upload.zip

As we know, deploying in OpsWorks is just a matter of click.

Screenshot from 2014-09-20 00:02:07

Note that deploying the OpsWorks app doesn’t mean running the service automatically. For that I need to use a deploy hook. Chef provides a way to execute a ruby script on steps in the deployment. Using the `before_restart.rb` I can execute a task that happens after the app directory changes its link from the old directory to the new deployed directory.

The content of `before_restart.rb` script is in below

script "runjar" do
    interpreter "bash"
    user "root"
    cwd release_path
    code <<-EOH
        java -jar *.jar > /var/log/springbootext1/app.log 2>&1 &
    EOH
end

I added the file in the `src/deploy` directory and I declare it as a resource in the POM file.

    <build>
        <resources>
            <resource>
                <!-- Creates directory for OpsWorks deploy hook -->
                <directory>src/deploy</directory>
                <targetPath>../deploy</targetPath>
            </resource>

The next question is how to shutdown the running service and update the new JAR. Spring Boot provides a production-ready feature called the actuator. Here I can put a shutdown for the service that will turn off the running service. To add the actuator, I define the dependency in the POM file.

<!-- cut -->
        <dependency>
            <!-- For deployment ready -->
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
<!-- cut -->

And in the deploy hook, before the run service script I added new script

script "shutdown" do
    interpreter "bash"
    user "root"
    cwd release_path
    code <<-EOH
        curl -XPOST "http://localhost:8080/shutdown" > /var/log/springbootext1/app.log 2>&1
    EOH
end

That script send a POST request to the current running service to shut itself down. As default the shutdown actuator is not enabled by default. I still need to add new configuration. To do this, I added a new file `scr/config/application.properties` and I added this line.

endpoints.shutdown.enabled=true

Spring Boot has a very flexible way of configuring the application. The simplest way is to have `config/application.properties` file in the JAR directory. The application JAR will check what’s inside the file and override the configuration.

The deploy directory also needs to be declared as resource in the POM file

<!-- cut -->
    <build>
        <resources>
            <!-- cut -->
            <resource>
                <!-- Creates config directory for external config --> 
                <directory>src/config</directory>
                <targetPath>../config</targetPath>
            </resource>
        </resources>
            <!-- cut -->

So now I have a minimum skeleton for deploying a small standalone HTTP service. Keep in mind to restrict the 8080 port by using AWS Security Group so that the 8080 port is only accessible to appropriate instances.

Regarding the deployment, I’m guessing there will be few seconds downtime between the shutdown and running new service. This can be even much longer if I put some long task in the shutdown listener. I’m still thinking how to do this more seamlessly. Ideas needed 😉

Another thing I can do is passing the custom JSON in the OpsWorks to the `application.properties` configuration file.

I can define something like this.

{
    "springboot-example": {
        "config": {
            "server.port" : 3333,
            "management.port": 3334
        }
    }
}

It’s a good idea to make the server port and the management port more configurable among other things. And I can write that JSON in the `application.properties` using the deploy hook `before_symlink.rb` and modify the `before_restart.rb` to use the custom JSON for the port numbers. This is very flexible since I can define the custom JSON in the Stack level and also in the deployment level.


I was just looking a good way to mount /tmp directory on AWS EC2 ephemeral storage automatically. Then I stumbled on this post. Nice method if you are using Ubuntu (or other distribution that uses Upstart).

# File /etc/init/mounted-mnt.conf

# mounted-mnt - Binds /tmp to /mnt/tmp

description     "Binds /tmp to /mnt/tmp"

start on mounted MOUNTPOINT=/mnt

task

script
    test -d /mnt/tmp || mkdir -m 1777 /mnt/tmp
    mount --bind /mnt/tmp /tmp
end script

And the good idea behind this, as told in the post, is

Some servers, like Apache/Passenger, might create important temporary files on /tmp. Once rc.local – the last in the boot sequence – ran they would get hidden and confuse the servers.


The WordPress.com stats helper monkeys prepared a 2012 annual report for this blog.

Here’s an excerpt:

4,329 films were submitted to the 2012 Cannes Film Festival. This blog had 25,000 views in 2012. If each view were a film, this blog would power 6 Film Festivals

Click here to see the complete report.


Ketika sedang membaca buku “Introduction to the Design & Analysis of Algorithms” karya Anany Levitin, saya merasa terinspirasi pada sebuah paragraf di bagian epilog yang membahas tentang algoritma paralel. Bertentangan dengan seisi buku tersebut yang membahas tentang algoritma sekuensial, bagian ini membahas mengenai kemajuan jaman yang telah menciptakan sebuah teknologi yang memungkinan sebuah proses komputasi bisa dibagi-bagi ke dalam beberapa subproses. Hasil dari sub-subproses ini nantinya akan digunakan untuk membangun hasil untuk proses keseluruhan.

Di paragraf tersebut diberikan contoh penjumlahan sebuah array A[1..n]. Dengan menggunakan algoritma sekuensial, penjumlahan ini akan menggunakan sebanyak n-1 operasi dasar penjumlahan. Sementara jika penjumlahan dilakukan dengan memasangkan tiap-tiap dua bilangan A[1] dan A[2], A[3] dan A[4], dan seterusnya kemudian menjumlahkannya secara paralel, maka langkah yang dilakukan hanya sebanyak \lceil{log_2 n}\rceil

Meski demikian banyak sekali tantangan yang harus dihadapi dalam melakukan komputasi paralel. Tantangan ini mulai dari algoritma, dependensi data, sinkronisasi, dan terutama dalam perangkat keras.

Dari beberapa pengalaman kecil, bisa saya katakan bahwa kendala perangkat keras adalah yang tersulit di antaranya. Sekarang ini banyak sekali perangkat keras yang sudah mendukung pemrosesan paralel, mulai dari yang paling prosesor multicore, graphical processing unit (yang sedang saya pelajari), hingga grid computing. Suatu algoritma sekuensial dapat dibandingkan satu sama lain dengan menggunakan pendekatan empiris pada mesin yang sama (meski kadang-kadang kita bisa menemukan beberapa ‘hal mistis’ yang terkait affinity). Tapi tidak sebaliknya dengan algoritma paralel yang jauh lebih kompleks daripada algoritma sekuensial yang bahkan implementasi dari satu mesin dengan mesin yang lain bisa sangat jauh berbeda.

Meski demikian, perkembangan pemrosesan paralel jauh menarik daripada pemrosesan tunggal. Jika kita lihat perkembangan clock speed komputer yang berkembang sangat perlahan, kita melihat sebuah booming pada perkembangan prosesor-prosesor paralel. Beberapa waktu belakangan ini saya sendiri melihat perkembangan yang sangat pesat dalam graphical processing unit yang konon diklaim lebih cepat daripada hukum Moore.

Di atas adalah sedikit pendapat pribadi mengenai komputasi paralel. Untuk beberapa waktu yang akan datang, saya juga akan menulis beberapa hal terkait hal ini.

Introduction to the Design & Analysis of Algorithms”Introduction to the Design & Analysis of Algorithms
%d blogger menyukai ini: