kubosho

day 1 （2017/5/7）

https://github.com/kubosho/my-os/tree/master/day1

アセンブリとバイナリエディタを初めて体験した。 はじめにバイナリエディタで16進数をひたすら入力して、それをimgファイルとして保存した。 その後アセンブリで書いたものをnasmでimgファイルに変換して、それをバイナリエディタで見てみた。

結果2つのファイルは多少違いこそあれど、QEMUなどの仮想マシン上にマウントして起動したらHello, worldと表示するだけのOSができた。 これがなかなか面白い。動作確認自体はqemuコマンドが brew install qemu としてもqemuコマンドがnot foundになってしまい、確認できなかったが…

minimum2scp

## for zsh user
docker () {
	local -a peco
	zparseopts -D -E -peco=peco
	if [ $#peco -eq 1 -a "${peco[1]}" = "--peco" ]
	then
		peco-docker "$@"
	else
		command docker "$@"
	fi

jashkenas

Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.

For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.

But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.

SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil

PeterAttardo

package com.example.util.shadow;

import android.graphics.Canvas;
import android.graphics.Color;
import android.graphics.Rect;
import android.graphics.drawable.GradientDrawable;
import android.view.View;

import static android.graphics.drawable.GradientDrawable.Orientation.LEFT_RIGHT;
import static android.graphics.drawable.GradientDrawable.Orientation.TOP_BOTTOM;

akisute

import Foundation

var l = [
    "abesi",
    "hidebu",
    "tawaba",
]

var m = [
    "abesi": 1,

Raynos

Virtual DOM and diffing algorithm

There was a [great article][1] about how react implements it's virtual DOM. There are some really interesting ideas in there but they are deeply buried in the implementation of the React framework.

However, it's possible to implement just the virtual DOM and diff algorithm on it's own as a set of independent modules.

branneman

Better local require() paths for Node.js

Problem

When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:

const Article = require('../../../../app/models/article');

Those suck for maintenance and they're ugly.

Possible solutions

jbenet

a simple git branching model (written in 2013)

This is a very simple git workflow. It (and variants) is in use by many people. I settled on it after using it very effectively at Athena. GitHub does something similar; Zach Holman mentioned it in this talk.

Update: Woah, thanks for all the attention. Didn't expect this simple rant to get popular.

tshrkmd

<?xml version="1.0" encoding="utf-8"?>
<resources>
  <style name="Theme.AppCompat.Light.NoActionBar" parent="@style/Theme.AppCompat.Light">
        <item name="android:windowNoTitle">true</item>
        <item name="windowActionBar">false</item> <!-- For 2.x version  -->
  </style>

</resources>

mizchi

花火~ 最高な俺たちと糞コードの海

written by mizchi at 小物エンジニアの会.

最高の夏の花火について

自己紹介