僕が触り始めた頃のウェブフロントエンド開発はデバッガーもなく、ダイナミックHTMLと呼ばれて文字をチカチカさせたりするようなものでした。IE6という超安定ブラウザが出てきたり（Netscape 4.xも7.xも不安定だった）その後jQueryが登場したときは、天使が降臨したように思えたものです。 そこから長い年月が経ち、ウェブフロントエンドの比重が大きくなるにつれ、フロントエンドのコードはどんどん複雑化しました。OpenAPIなどのコードジェネレータなども普及した結果、通信というものが隠され、イベントの中でawaitや.then()で呼ばれる何か、みたいな理解をしているメンバーも今後増えていくのではないかという懸念があります。 現在ではウェブフロントエンド開発はReactやVueといったフレームワーク上で行われ、イベントというのはそのフレームワークの提供するライフサイクルイベントに対応付け
はじめにもともとはMicrosof Visioなどを使って作成していた図形（ネットワーク図、各種シーケンス、ERD..etc）ですが、ファイルストレージがクラウド（Google Drive）に移ることで、 そのまま編集したい 欲求が世の中で増しているように思います。 その場合の有効なツールとしてdraw.ioを利用するケースが増えてきたと感じます。そこで当社で蓄積したナレッジを文章化します。 Draw.io Tips1.ショートカット1.1. 公式ショートカットまずはここから始めましょう。 ショートカットはプロダクトの基本操作が詰まっています。 https://about.draw.io/wp-content/uploads/2016/11/draw.io_shortcuts_basic_win_EN.pdf 2. 設定2.1. 日本語化 画面右上の🌏マークから選択します メニューが開く
このエントリーはSayanさんによるUnderstanding the AGPL: The Most Misunderstood Licenseの日本語訳になります。 オープンソースの出現は、ソフトウェア産業全体を一変させました。しかし、オープンソースのコードを使って誰が何をできるかを管理することは課題でしたし、今も解決していません。オープンソースライセンスはそこに救いの手を差し伸べました。しかし、常に次のことを忘れないでください：石のない土地はなく、骨のない肉はありません。OSI（オープンソースイニシアチブ: オープンソースを促進することを目的とする組織）が承認したライセンスは80以上あり、その数はさらに増加しています。それぞれのライセンスには利点と欠点があるため、オープンソースの開発者は自分のプロジェクトにあったライセンスを選ぶのは簡単ではありません。Affero General Pu
はじめにTIG真野です。説明資料のスライドを作成するときにチームメンバーによくフィードバックしたポイントをまとめました。 以下この記事の前提です。 Google Slideなどのスライド形式が前提です わざわざスライド化しなくてMarkdownに箇条書きで良い場面も多いと思います。先輩はマインドマップでディスカッションしていて憧れました。ただ、この記事ではスライド前提とさせてください 5,6名のメンバーと気合を入れて資料作成し、数ヶ月かけてドメインエキスパートとディスカッションしました経験のまとめです 作成した資料は議論のたたき台＋システム設計における要件定義のような位置づけで用いました 資料はフルリモート会議で用いたので、なるべくスライドだけで完結して伝わるような志向があります この記事の記載内容は資料作成の全てのユースケースで使えるわけじゃないです コンテキストを共有しているチームメン
フロントエンド連載の5記事目です。 HTML5が2021年の1月に廃止されました。 Webエンジニアとしてバリバリ活躍されてる方やエグゼクティブテックリードのような肩書きを持つ方にとっては「何をいまさら」という話題かと思います。 しかしながら、今年も新人さん入ってきてくださったので、プログラミングを学習中にHTML5という文字列に悩まされないように、そもそもHTML5とは何かや、廃止された経緯をまとめてみます。 HTML5とはWebサイトを作るときに必ず書くことになるHTML。Webサイトのコンテンツ、つまり中身や構造を作るために使うマークアップ言語です。 そして、その最近版として10年ほど前に登場したHTML5。当時は Webニュースなどで盛んに特集が組まれていましたが、このHTML5がついこないだ、2021年1月28日に廃止されました。 広義のHTML5 / 狭義のHTML5HTML5
はじめに現在所属しているプロジェクトではWeb APIやバッチ処理の設計の一環としてPlantUMLを利用しています。効率よく品質高くアウトプットを出すためには、プログラミング言語に対してコーディング規約があるように、UMLに対してもチームで設計するにあたり一定のルールを決める必要があります。 そこでプロジェクト内のPlantUMLを使用するうえでのガイドラインやルールをまとめる機会があり、せっかくなのでそれを記事化します。 記事のゴール シーケンス図設計におけるPlantUMLの標準化 必要最低限のルールだけに絞ってチーム設計の生産性と品質を上げる 記事の前提 ルールの想定の利用シーン： チームで大量生産する業務機能の処理フローを表現するために使う場合を想定。 また、この記事に記載されているルールはRDBを中心的に使用したAPI処理やバッチ処理等を念頭に置き決められたものです。 ルールの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
