The Whys and Hows of Promise in JavaScript
If you have done any web development after 2015, chances are that you have heard of the concept of Promise. It wouldn’t be an overstatement to claim that Promise is ubiquitous in modern-day front-end codebases. However, many web developers—especially those who do not have much experience in front-end development—have been using Promise without thoroughly understanding its inner working....All You Need to Know about Isolation Levels and Read Inconsistencies
Just like real life, the world of computer science is replete with trade-offs. Relational databases are no exception. When interacting with relational databases, we face the dilemma between data consistency and transaction concurrency. The former guarantees the data is trustworthy, while the latter ensures relational databases can conduct transactions swiftly. Both are desirable qualities of relational databases, but we cannot simultaneously achieve them to the fullest extent....CAP Theorem But Better? Introduce the PACELC Theorem
In the previous blog, I introduced the famous CAP Theorem (please give it a read if you haven’t already before you start reading this one). It involves a trilemma of needing to give up one of the following three qualities: consistency, availability, and partition tolerance. Since all three are desirable features of modern-day distributed systems, determining which one to relinquish has become one of the most important and delicate decisions for designers of complicated distributed systems....What You Need to Know about the CAP Theorem
The world that we live in is far from perfect. We constantly find ourselves in dilemmas, sometimes even trilemmas, that require us to make trade-offs. When shopping, we can only choose two out of “cheap,” “fast,” and “good.” In economics, a government cannot enjoy “sovereign monetary policy,” “fixed exchange rate,” and “free capital flow” at the same time....A Brief Introduction to Kafka
There’s no denying that we have already ushered in the era of big data. An enormous amount of information is generated every second. While decision-makers can gain invaluable insights from this ever-growing data, its sheer volume also poses considerable challenges to data engineers–greater demand for storage spaces, the need to handle increasingly complex data formats, and highly unpredictable network traffic....A Brief Introduction to the Inner Working of MapReduce
As a data engineer, you probably have heard about Hadoop. It is one of the most popular frameworks for distributed processing of large data sets. It is less costly and more secure than other frameworks. At its center is a programming model called MapReduce. Today we will take a closer look at MapReduce to understand the inner working of Hadoop....ETL vs. ELT: Pick the Most Suitable Data Integration Method for Your Project
As a data engineer, you probably have heard of the data integration methodology called ETL (Extract-Transform-Load). It has been around for a while, and many data engineers have used this methodology to build data pipelines. However, ETL is not the only option up our sleeves. Recently, ELT has also been gaining a lot of popularity....プログラミングにまつわる今昔物語
はじめに こんにちは。Colorkrew(以下CK)の老人プログラマー TORIIです。 さて今日はColorkrewプログラミング老人会のトップ3(正確にはよくわからない)である私からプログラミングにまつわる今昔な話をしたいと思います。 実際のところ世の中のプログラミング老人会的にはまだまだ私なんぞ若造もいいところなのですが、最近我が社では若くてフレッシュでピッチピチなエンジニアが続々と増えたのに対し老人層が心持ち減ってしまい気がついたらそうなっていたのです。ただ座っていたらそうなっていたのです。実に不思議なこともあるものです。 では早速始めましょう。 第1話 エンジニアとプログラマ 人類開闢以来、上流工程を取り扱うシステムエンジニアと呼ばれている人は大勢いましたが、この10年くらいでプログラムを書くことを生業とするエンジニアと呼ぶ人が随分と増えました。 いやもっと前からそうだったのかもしれませんが、正直いつから増殖を始めたのかよくわかりません。主観的な印象としてはいきなり増えた印象です。それはもうワラワラと。 一体全体、エンジニアとプログラマの違いは何なのでしょうね。 私がエンジニアを自称し始めたのはたしか2010年代の前半だったと思いますがそれ以前は自分をプログラマだと思っていました。 変わるきっかけになったのは名刺に役職を記載するときに会社のルール上「プロデューサー」と書きなさいと言われ「いや違うし」と抗議し調整した結果、上長と相談の上決めることとなった時に、最初「なんちゃってプログラマ」にしたいと言ったところ何故か却下されたので、渋々「ソフトウェアエンジニア」と書いた、というのがきっかけです。 一般的によく言われているプログラマとは誰かが作った設計書をもとにコーディングとか修正しかしない人を指すらしいです。あるいはマネジメントをしない人だとか。 エンジニアの方は俗説では工学系の学位を持った人のことだという説もあったようで、実際海外では学位がないとIT系に就職しづらい国もあるらしいです。 日本ではもちろんそんな学位は必要ありません。小学生でもエンジニアを自称できます。 本当に業界や状況・文脈によって変わってくるし、今はプログラムを書かないIT職種も多数ありそれらもエンジニアと呼ばれるので、プログラムを書く人間にとっては基本的には気分の問題(プログラマというよりエンジニアと言ったほうがすごそうに聞こえる)であってそういう様々なIT系の職種を含めた総称と考えるのが良さそうですね。 そういうわけで今ではすっかり私もエンジニアと呼んでいます。でも心では永遠のプログラマなのです。 第2話 タブとスペースと括弧 ソースコードのインデントにタブとスペースどちらを使うのか、というお話です。 前はタブが多かった印象でしたが、今はほぼスペースが用いられていますね。なんだか知らないうちに決着がついていました。いやびっくりですね。 タブの問題点は構造化以外の目的で使うとレイアウトが崩れるところにあるのはわかっています。 でもスペースはスペースで、スペース/バックスペースN回押して書いていくのは面倒ですし、回数を間違えるとインデントがずれます。コピペの時にカーソルの位置がずれることもあります。 え？ タブキーを押すだけだろうって？ それはエディタの力(ソフトタブ)ですね。 優秀なプログラミングエディタを使った場合ほぼ問題は起きません。普通のプログラミングエディタの場合だとうっかりスペースの途中からコピーしたりすると1文字過不足のあるインデント行が発生したりします。1文字ズレだと結構気づかないんですよね。 最悪なのでがソフトタブ自体がないチープなエディタしか使えない場合で、N回スペースを連打しないといけないため「スペースをインデントで使うことを指示した奴は何を考えてるんだ」と呪いたくなるほどの苦痛と化します。 まぁ、そんな環境今では稀なのでスペースで全く問題ありませんね、ええ。 年に何回かは部分的に1文字過不足のあるインデントになってしまうことがあるにはあるのですが、見かけたら直すくらいで存在自体は特に気にしないことにしています（あ、見かけたらプルリクエスト出しておいてくださいね）。 同じような話でifやforなどの制御文の括弧の開始位置をどこにするのか、という話もありますね。制御分と同じ行の最後に書くか次の行に書くかというアレです。 今はC#とかの一部の言語以外は制御文と同じ行に書くのが主流らしいですね。 私もプログラムを書き始めた時は制御文と同じ行に書いていましたが、一番最初の仕事でやったプロジェクトで括弧の開始と終了の位置が離れると対応が合わなくなるエラーが頻発したことがありました。この書き方だとどこの括弧が不足・過分になっているか・インデントがおかしいのか一見して全くわからないのです。 まぁそんな位置が離れてるような制御文を書くな、関数化しろという話ではあるのですが、若気の至りなのです。 switch文のラベルの数が1000だったかそこらまでしか対応していないコンパイラなのに、それを超えてしまって謎の不具合が発生したことがあるくらい、そんなへっぽこコンパイラと同レベルのアホだったのです。 そこで、次の行に括弧の開始を書くというスタイルに変えました。 すると途端にそんな間抜けなエラーは起きなくなりました。次の行に括弧開始がなければインデントされないので一目見るだけでどこに異常があるのかわかるからです。最高です。 以来ずっと個人で書くときはその書き方をしています。 でも今の世の中はそんな最高の書き方はしないようです。恐らく括弧の開始行だけで１行消費するのが許せないのが一番の要因だと思いますが、(エディタの力などで)括弧の対応が取れなくなるようなことが起きにくくなっているのでしょう。 まぁタブ・スペースの話も括弧の話も今はどんな書き方をしたとしても、保存した瞬間にエディタによってプロジェクトで定められたフォーマットに従って自動的に修正されるので、書くだけならどんなスタイルで書いても良いというのはいい時代になりましたね。 第3話 ライセンス表記 私がまだピッチピチの新人だった頃、新人研修でソースコードの先頭には会社名のライセンス表記を書きなさいと教わりました。 日本の著作権法的には書かなくても良いのですが、どうせファイルの説明文を載せるのだからついでに書いておけば良い、というくらいの認識でした。 しかしこのWeb業界、というかColorkrewではオープンソースのソースコードにはしっかりとしたライセンス表記はあれど、自分達で書いているソースコードにはライセンス表記を書いているのを見たことがありません。ファイルの内容を説明するヘッダも見たことがありません。(*1) 記述する風習自体がないようです。最初は不思議に思っていたのですが、最近は書かなくてもいいかな、と思い始めてきました。 書かなくても著作権は成立するし、万が一ソースコードが漏れた場合……とか思ったので。 でも自社プロダクトのソースコードにはきちんとつけておいた方がいいんじゃないかな、と思う今日この頃です。 さいごに 駄文を書き連ねて参りましたが、好評であれば続くかもしれません。 弊社Colorkrewのプログラミング老人会では会員……もとい社員を随時募集中でございます。...Welcome to Colorkrew Biz Developer Camp
Hi, I’m Alessandro. The Colorkrew Biz team recently went on a company camp at the Enoshima Beach House to make up for the disruptions caused by COVID-19. While the team had done well with remote work, the employer knew that in-person interactions and team bonding were important. We spent two days in a dreamy Beach House in the stunning Enoshima, partying and enjoying yourselves with our teammates....All You Need to Know about Lazy Evaluation in Spark
Few would disagree that the word “lazy” has a negative connotation. We usually describe someone who is not willing to work hard as lazy. However, not all laziness is undesirable, and sometimes we prefer laziness to diligence, especially in the computer science world. One example is lazy evaluation. Today, we will closely inspect why lazy evaluation is essential to Spark’s high performance and how lazy evaluation works in Spark....Parquet Files: Smaller and Faster than CSV
If you have been in the world of big data long enough, you probably have heard about Parquet files. You might even have used it while thinking to yourself: “why can’t we just use CSV files?” Today, I will debunk the mystery of Parquet files and explain why a growing number of data scientists prefer Parquet files to CSV files....Actions, Narrow Transformations, and Wide Transformations
Hi! My name is Ziyu Chen. I am a full-stack engineer at Colorkrew. I love learning and writing about data engineering. Today, I would like to discuss transformations and actions in Spark. Of course, you can dive into the world of Spark and perform ETL processes without knowing how they differ from each other....Dependency Injection with Laravel
Dependency Injection - With Laravel Dependency injection is a commonly used design pattern in object oriented programming. Through some pre-established conventions, we are able to manage the creation of our dependencies more easily. We can declare, replace, or even mock the dependencies as needed without the need to change the code that relies on the dependency....The Power of TypeScript Types
Any frontend developer knows the frustration of seeing the infamous “is not a function” message pop up. It reminds you that, even though your code might achieve your goal, you will not be able to assure its consistency or reliability. Without strict typing there is no stopping tiny slip-ups due to a lack of coffee - or sleep, depending on your dedication....