プログラミングにおける不安と学びのプロセス - 人間とウェブの未来
僕の場合、実現したいことをコードで書けない時には、ひたすら似たコードを読んで理解して写して…を繰り返す。そのうちに手元に大量の自分のサンプルが溜まっていく。その繰り返しがパターンの細分化を促し、書けるコードの幅を広げていく。書けるコードを気持ちよく書き続けてるだけでは新しいコードは書けないからだ....と、向き合えるようになるには時間がかかった。 書き慣れたコードの延長で書いていると、自分でコードを書けている実感があって、リファレンスなど何も見ずに自分の力でプログラミングできている感があるのだが、ある時これはただ「慣れ」の感覚を高めているように思えた。素早く書けること自体は、それはそれで一種のスキルで素晴らしいのだけど、実現したいことをコードで書けるようになる、という観点で振り返ったときに、どうしても成長を感じなかったのだ。それ以来、まずいと思い、実現したいことを思い描き、それを実現するた
「プログラマの三大美徳」と「HRT」を使い分ける - 「コードを憎んで人を憎まず」 - TechとPoemeの間
TL; DR 「プログラマの三大美徳」はソフトウェアに向けるものであり，人に向けるものではない． 「HRT」は人に向けるものであり，ソフトウェアに向けるものではない． プログラマの三大美徳 プログラマの三大美徳というものがある．Perl を開発した Larry Wall が提唱したもので，「怠慢」「短気」「傲慢」からなる． 詳しくは上述のリンクにある各解説記事に譲るのだけど，例えば「怠慢」とは，「エンジニアとして手間を省くために最大限の努力をする気質」を指す．元の Larry Wall の記述では当たり前過ぎて省略されているのだけど，「最大限の努力」とは「仕事をしないために交渉する努力」ではなく「技術で手間を解決する努力」を指すものだと思われる (勿論，場合によっては前者が大事になるケースも有るのだけれど) ． 「プログラマの三大美徳は "怠慢", "短気", "傲慢" である」というワー
Pythonによるデザインパターン5原則 - Qiita
参考 @kidach1 さんの投稿をPythonに書き換えてるだけです。 @kidach1 さん、いつもありがとうございます。 https://qiita.com/kidach1/items/4b63de9ad5a97726c50c 概要 改めて基本を学ぶ。 参考「Rubyによるデザインパターン第1章」→この投稿はPython デザインパターンとは プログラミングにおいて繰り返し現れる問題に対する、適切解のパターン。 無駄無く設計されたオブジェクト指向プログラムの実現をサポート。 パターンとしてカタログ化されていることで 車輪の再発明を防ぐ デザインパターンの根底にある5つの考え 変わるものを変わらないものから分離する プログラムはインターフェイスに対して行う（実装に対して行わない） 継承より集約 委譲、委譲、委譲 必要になるまで作るな（YAGNI） 変わるものを変わらないものから分離する
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
コードレビューにおけるレビュアー側のアンチパターン
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
イマドキのJavaScriptの書き方2018
PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」（よりよい代替がある）というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前の本やウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計の４つの基本活動、Springのプログラミングモデル、ドメイン駆動設計のためのSpringの使い方Read less
新しいプログラミング言語の学び方 HTTPサーバーを作って学ぶ Java, Scala, Clojure
JJUG CCC 2017 Fallでの発表資料です。
Web屋の私が勘違いしていた、世界のネット通信環境の驚くべき状況
ユーザーの目線でWebサイトを作ることは基本中の基本ですが、グローバルサイトを担当することになったら日本の常識を捨てて現地の状況を理解する必要があります。 アプリやWebサイトをより良く、より速く、よりアクセシブルにする手助けが私の仕事です。CalibreでWebを構築したり、メンテしたりする際にぶつかる課題について、知見が集まりました。 この1年で本当に驚いたことは、一般のユーザーがどうインターネットにアクセスしているかです。Web業界に従事しているのに、ほとんど理解していませんでした。自分たちがユーザーにコンテンツを配信する方法がいかに時代遅だったのかもわかりました。 ここ数年の進歩で、コンテンツをWebからダウンロードする速度は劇的に速くなりました。しかし、「HTMLをロードし、ほかのリソースを探してそれもロードする」という基本は変化していません。 世界中の約46.1%がインターネッ
React Redux を用いた SPA 新規サービスを運用して得た知見と実装例 | ランサーズ（Lancers）エンジニアブログ
@tsuyoshi です。先日行われた React Redux を用いた SPA 新規サービスを運用して得た知見と実装例 と言うイベントで使ったスライドをアップロードしました。 https://pook.life/ と言うサービスをReact Redux の SPA で運用して得た知見などを共有できればと思い。公開してみた次第です。 内容としては 利用しているライブラリや開発環境、開発フロー コードベースでの実装例の紹介 その他 SPA サービスを運用する上での構成や知見 など、実例や結果を交えながら説明しています。 何かの参考になれば幸いです。 スライドを貼ってますが、以下のgoogle スライドで見た方が、アニメーションとか動いて見やすいかもしれません。 https://docs.google.com/presentation/d/1TIEg5rYJ9vlWTSO6etwupBBO0e
「フロントエンド開発に再入門する」タスクフォースの進め方 | MEDLEY Developer Portal
2017-11-09「フロントエンド開発に再入門する」タスクフォースの進め方こんにちは。開発本部の宍戸です。 メドレーでは定期的に、テーマに沿って組織の技術的な底上げを行うための機会（タスクフォースと呼んでいます）を行っています。そのタスクフォースの１つとして先日、フロントエンド開発力のベースアップを目的としたタスクフォースを行いました。本記事では、その取組みについてご紹介したいと思います。 背景メドレーには現在 20 人弱のエンジニアが在籍しており、その約半数がサーバーサイド出身者です。また普段の開発においては、一つの機能をフロントからサーバーサイドまで一貫して一人が担当するケースが多くあります。サーバーサイド出身者のフロントエンド開発のスキルセットには多少ばらつきはあるものの、普段の開発業務ではレビュー等でそれぞれサポートしつつ開発を行っています。 しかし、フロントエンドの基礎的な部分
IT導入/要件定義の前に、PoCの時間を取ってもらえませんか？ | (株) クオリティスタート
IT導入を行うにあたって、非常に多いのが「カタログや画面、説明を聞いていたらこのソフトやシステムで問題ないと思っていたが、実際に納品されたものと使ってみると使いづらかった。期待したものではなかった。」という失敗談です。そういったすれ違いを可能な限り少なくするために、ITシステムを導入するために何をどう考えなければならないのかを解説します。 「要望」と「要件」がもたらすギャップ システムを手に入れる過程は、注文住宅を作る過程によく似ています。 リビングは12帖以上 書斎が欲しい 床の木からぬくもりを感じたい 寒がりなので断熱効果を高めたい これが要求、つまり成し遂げてほしいことです。使う人が作る人に対して、伝えるべきことです。 これに対し「要件」というものは、こういうことになります。 12帖のリビングにするために、書斎の場所は収納になるが良いか？ 断熱効果を高めるための素材はこれでいいか？
Spotify Modelは"アジャイルの涅槃"ではない
Spotifyでは、マネジメントと組織の動きは人を育てることによってチームとアジャイルの実践を支援している。しかし、Spotifyは"アジャイルの涅槃"ではない。継続的に成長し、変化し、新しいチームに分裂するような高い成果を産むチームに達するのは難しい。Spotifyのチームとリーダーシップのコーチを務めるJoakim Sundén氏は、ビジョンを持ち続け、小さなステップを刻みながら向かうことを推奨している。 Sundén氏はSpotifyでのスムーズに進まなかった問題やどのようにその問題を解決しようとしたのかについてLean Agile Scotland 2017で語った。InfoQはこのカンファレンスの模様をインタビューや記事で取り上げている。 InfoQはSundén氏にインタビューし、うまくいかなかったことが製品にどのような影響を与えたのか、Spotifyでエンジニアリングマネージ
『わかばちゃんと学ぶ Git使い方入門』を読んだ - 30歳からのプログラミング
同僚にお借りして読んだ。 わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉 全くの初心者向けに、GitやGitHubの使い方を解説した本。 漫画の主人公も、プログラマではなく「Web業界に憧れる大学生」。 コマンドラインではなくGUIで操作していき、写真も豊富で分かりやすい。Gitの説明そのものも分かりやすかった。 「Git入門」を謳った教材は多いが、自分が見たなかでは本書が一番理解しやすかった。 既にある程度知識がある状態で読んだからかもしれないけれど。 最初にGitについて学ぼうとしたとき、ステージという概念がよく分からずイメージできなかったが、本書ではコミットを「その状態を写真に撮る」、ステージングを「撮影台に載せる」と説明してあり、分かりやすかった。 仕事で日常的にGitを使っているから本書の内容は大体知っていたが、初学者向けの本書を読
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える - pospomeのプログラミング日記
devfest 2017 tokyo の発表資料です。 Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える from pospome 当日は入室できない人もいたらしい & 機材トラブルで10minほど開始が遅れてしまった ということで申し訳なく思っています。 また、立ち見する価値がある内容を提供できたのだろうか? とも思っています。 スライドは単体でも発表内容が伝わるように文章を多めに載せているので、 是非確認してみてください。 100ページ越えていますが・・・。 #DevFest_room2 入れなかった。。— t.junichi (@tjun1) 2017年10月9日 ものすごい立ち見人数 #Devfest17 #DevFest_room2— バトルプログラマー柴田智也@少女終末旅行 (@tomoya_shibata) 2017年10月9日 ルーム2これから並ぶ方はま
Gitの良さが分からない？ ちょっとそこに座れ | To Be Decided
Gitの良さがいまだに分からないという人がいるようなので、Git派の一人としてSubversion(以下SVN)と比較してのGitの良さ(メリット)について語りたい。 (GitとSVNの違いについては他の人の記事に詳しいのであまり書いていない一方、勢い余ってGitのデメリットも書いた。) 本題に入る前に、冒頭にリンクを貼った記事についてひとつだけつっこんでおく。 つっこみどころは他にも沢山あるけど。 ※話の前提としてgitとSVNを採用している現場に下記のような割と違いがあるとする。 git イシューごとにブランチを切り、ローカルでコミットして、リモートブランチにpushして、GitHub・GitLab・Bitbucket経由でマージリクエスト。コードレビューの後にマージ。 SVN リモートのtrunkに個々人が直接コミット。コードレビューはあまりない。ブランチを切ることもない。 このよう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
組織にテストを書く文化を根付かせる戦略と戦術 / Strategy and Tactics of Building Automated Testing Culture into Organization
Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。 – ゆびてく
まなび（教育・進路） | 株式会社リクルート
DDD失敗談を話して学んだこと
