Sunday, November 26, 2017

暇だったのでアンビエント作ったお

Thursday, November 23, 2017

How to clean up your storage in MacOSX?

Mainly, in terminal, you often use

$df -h

Command to show the storage status how much it has been used and the percentage of it.

Yet this does not help you if finding out which exactly the directory contains large portion of memory so that you need to clean it up. In order to do this, in Linux, you can use sort command and pass the result of du output to it, but in MacOSX, first you need to use gsort.


brew install coreutils
du -hs * | gsort -h
 
 
It requires your Ruby version after 2.3.1, so if 
there are any troubles, please 
see the link below and update the Ruby app appropriately.
 
 
how to update your Ruby version
 
 
 
https://sirotosky.bandcamp.com/music 
 

Monday, November 20, 2017

ひろみん大ピンチ




どうなるひろみん

最近歯医者に行ったのだが

虫歯自体はなかったんだけど、色素が沈着して歯の表面の中に入っているみたいで、まるで虫歯のように見えるため、それを削って色を抜くという方向性で決まった。

やはり定期的に行くべきだと思った。

あとホワイトニングもやります。

以上。

Tuesday, November 14, 2017

Sunday, November 12, 2017

OOP explained -DESIGN -

OOP design has SOLID principle.

- Single Responsibility Principle (SRP)
- Open Closed Principle
- Liskov's Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle

Single Responsibility Principle (SRP)

SRP is so simple. Each class must have only one responsibility for it. Any class should not have more than one responsibility. (For example, Apple class should not have any  methods handling Banana)

Open Closed Principle

It means Open for extension and Closed for modification so that you can easily add new main features to it. This is vital aspect since we need to keep high maintainability of our code base.

Liskov's Substitution Principle

Each class of the same level (inheriting from the same abstract class) should be interchangeable.
In Ruby, for instance, something like:

1.to_s
/^[\/{3}\-]+$/.to_s
"abc".to_s

These above belong to totally different types, but even though they are of different classes but shares the same method to_s which enables it to convert to String since their super class Object has it.

Interface Segregation Principle

Each interface should be segregated and should not included the method which is not required to that particular interface.

Dependency Inversion Principle

Abstract class should be in the middle between interfaces, and details relies on abstract but not vice versa. Like:


class Base::Provider
  def slice
  end
end

class Apple::Provider < Base::Provider
  def slice
  end
end

class Banana::Provider < Base::Provider
  def slice
  end
  def burn
  end
end

class Controller < ActiveRecord
  def create
    backend.provider.slice     
  end
end


Something like this. In OOP we should not dispatch directly to each class implementation or, to say, DSL but we need abstract class in the middle and let it dispatch to the detailed polymorphic classes.



http://www.oodesign.com/dependency-inversion-principle.html

OOP explained (1) -CONCEPT-


This article is a summary on the video above.

Object Oriented Programming (OOP) is preceded by the Machine Language, Assembly Language, and Procedural Language (like C), and the concept of it is to let it similar as the thing-in-itself in natural environment. We perceive external world as the collection of Objects.

OOP has the following features:

1. Object
2. Class
3. Abstraction
4. Encapsulation
5. Inheritance
6. Polymorphism


1. Object

While procedural language only has global variables and bunch of functions accessing to each of those, this also means that there are no independent entities, just nothing but the pile of chunks. (Even though C has modules)... Relying on global variables is often risky since then variable becomes accessible to which are not supposed to. The concept of Object is that to make it split into a unit easy to understand. On this paradigm everything is regarded as an Object. For instance, EMPOLYEE can be a single object, and it can have the attributes (instance variables) and functions(methods).

2. Class

Class is a template for the Object. Object is, on the other hand the instantiated copy of this class.
For instance,


String x;


This definition means there is Type (String) and variable (x), String is the class template since it is generated only once, but x is the object of String since it is a instantiated variable (copy) of that template. (Singleton is an entity only generated once, accessible from anywhere, seems little bit like a class)


3. Abstraction

In order to define the class, OOP thinks we should not expose what is not necessary, so the number of methods are ABSTRACTED (filtered) just only which is crucial as the part of interface to connect with external something.


4. Encapsulation

Little bit similar to Abstraction (Since only what is necessary as interface should be exposed as public but else should be eliminated from class or be private). For example, vending machine only has button and coin-slot and box to retrieve cans for customers, it is kind of interfaces nevertheless it has so much components inside of it.


5,6 Inheritance, Polymorphism

Child inherits from its parent. Parent should be abstracted as much as possible since all the peculiar detail should be defined and implemented in each child classes. Also, Polymorphism means a single definition of class can be implemented in various ways as its child node. For instance, if the superclass is defined as OS, then we can define each object as MACOSX, MSDOS, UBUNTU, FREEBSD etc....


So these six are main concepts of the OOP. In the next article, I would like to introduce the SOLID principle.

Saturday, November 11, 2017

The nursery robot and its development

The development and deploying the Nursery Robot is the top priority taking the current demographic situation in the developed nation in to account. Yet in Japan Government and private company, are trying to launch the project off the point. We need to take the approach to solve this issue from the following viewpoints:

How to physically assist the target in the following:

- wake up from the bed
- bring up from the bed and let & keep him/her stand
- how to let him/her walk
- how to let them walk to the toilet
  - take off the pants
  - sit down on the toilet
  - the support of him/her to deal with the excrement, wipe it out and wash
  - take on the pants
  - get out of the toilet

- Bath
  - {similar procedures}

- Eatings
  - {similar procedures}

The labors which caregivers do could be broke down into these imperative process, and each single procedure needs to be implemented, with the safety taken into account.

This at least requires the following:

- Interface such as:
  - visual sensor device to grasp the target
    -  feature to recognize the "excrement"
  - audio device (Siri or something) to accept the command input
  - arms and legs to physically support the target
  - Network interface (or backdoor) to accept the OS / app updates to fix bugs or apply additional features or the external data as part of the machine learning or analysis.
  - ....


The thing is average Japanese are not that smart enough to do the STUPID attempts as I stated above. Maybe foreigners could launch some venture project to achieve this and I will promise that the company make a lot of money in the developed nation which suffers from excessive amount of old people.

We immediately need to study and apply IoT and AI related technology to solve this nursery related issue because this could hinder us the potential labor force contribute fully to our society.


To make excuse for just screaming Safety can deprive us of any innovation opportunity to drastically solve the current social problem.


For instance, the image above does reduce the pain of caregivers since the robot is going to grasp the target and let him/her sit down and bring to the target location. The crucial implementation is sensor and AI related thing(and detailed mechanism how each finger works appropriately). The shower included since sometimes we need to clean the testicles/vagina of the target.

We have to deprive every single human labor of the caregivers.

I have re-arranged my past song "Garan"



I recently am into remixing my past songs, which is on the LogicX repository, and altering the instruments and find out the better way of expressing and integrating the individual tracks are really good experience for me. Garan is composed in the concept to design the Buddhist Temple, originally it refers to 伽藍堂(Garan Do).





What we need here is the appropriate EQ which make the non-drum related instruments clear and strong, but not the excessive enough to let it in good order. And of course you need to modify the pitch if it may contribute to the air of the song composition.

Hope people enjoy my song.

Sunday, November 5, 2017

また過去のラップをリミックスしてみた


今回のリミックスで発見したこと(まだ音圧とか各トラックの音域のそぎ落としが完了していないので、若干汚いけど)は、

- 楽器(DTMのインストルメントのこと) によっては倍音がごちゃ混ぜになることでネタに奥ゆかしさを出せること
- リバーブは諸刃の剣で、場合によってはヒップホップらしさがなくなるので、バランスが必要
- 声を、メインの外のコーラスのピッチを若干だけずらすことで(そしてメインは買えない)ちょっと、声が盛れるということ

くらいか。

また後日アプデしていく