こんにちは！ エンジニアのまうみです。 突然ですが、「今使ってるブログサービスからWordPressに引っ越ししたい」と検討中の方はいらっしゃいますか。 もし、現在のブログサービスに記事をエクスポートする機能がない場合、手作業で記事を更新する必要があります。10記事程度ならまだしも、100記事以上ともなると、それは流石に手作業では骨が折れますね。 そこで今回はGoogle Apps Script（以下：GAS）で、スクレイピングしたデータをスプレッドシートに保存するプログラムを作り方をご紹介します。 【前提】スクレイピングとは スクレイピングとは、あらかじめ指定したWebサイトを巡回して情報を取得し、新たな情報を出力するためのプログラムです。 今回は、開発環境を構築することなく簡単にプログラムを実行できるGASを使用します。特に開発環境は初心者がつまづくところなので、そこをスキップできるの

0.はじめに 1.簡単な自己紹介 2.年をとるにつれて衰える能力 3.低下した記憶力で競プロに取り組む 4.AtCoderのレベル感 5.競プロ上達への道のり 6.競プロとの向き合い方 7.競プロの依存性 8.競プロのコミュニティ 7.これから 8.終わりに 9.＜番外編＞もし後悔があるとすれば 0.はじめに こんにちは。競技プログラミング歴一年半のかえでです。 私はAtCoder Problems でLongest Streak にチャレンジしています。Longest Streakは、これまで解いたことのない問題から一日一問以上解いた連続日数を競うものです。今日、この記録が500日に到達しました。私は解説ACもするので、純粋に自分の力で解いた問題ばかりではありません。それでも、こつこつと続けてきた自分を、ほめてもよいのではないかという気持ちになりました。 ここまで長く続けられたのは、At

また変なタイトルをつけてしまいました。努力する事についてのお話です。 僕のこんな話を聞いてくれるのは大体絵を描いている人だと思うので、その前提で話しますが、皆さんは日々絵が上手くなるための努力をしていますか？そして努力に見合った成果をえていますか？ 僕は、19歳の時に本格的に絵の勉強を始めて、自分なりに努力はしていましたが、絵を始めて当初は、かけた労力と時間に対して、それに見合うような成果を得られた、という感覚はほとんど持てすにいました。 これについては僕だけではなく、多くの人がすごく努力してるのに思ったほど上手くならない、という経験をしているのではないかと思います。 どうして努力が思ったほど報われない、と感じるのでしょう？結論を先に言うと、これは時間感覚に対する遠近法の問題です。僕らは、今目の前で起きている事は巨大に、遠い未来の事ほど、小さくぼんやりして見えます。つまり、努力は今やる事で

以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P…

この記事について 自分の所属するチームに、自動テストを書いたことがないメンバーが加わったとき、ガイドラインとなるようなドキュメントがほしいなと思っていたので、書きました。どうせなら他のチームでも使いたいので、ドメインはぼかして汎用的になるようにして公開します。独自のベストプラクティス的なものですが、これまでのチームではわりとどこもこれに近くうまくいっていたので、汎用的に使えるんじゃないかと想像します。 はじめに 環境 Laravel: 5.8 以上 PHP: 7.0 以上 PHPUnit: 7.0 以上 いちおうバージョンは書きましたが、あまり関係はないです。 基本方針 基本方針は、自分の経験上これがいちばんコストパフォーマンスがいいと思っているガイドラインですが、自分はベンチャーやスタートアップ企業で、スピード重視の文化に身を置くことが多いため、テストは最低限にして、素早くリリースするの

こんにちは、Development Teamの三宅です。 先日、社内（AI事業本部内）でSQL研修の講師を担当したので、今回はその内容について簡単に共有したいと思います。 はじめに 例年、AI事業本部では、新卒エンジニアの育成のためにソフトウェアエンジニア研修を行っております。今年はフルリモートでの実施となりました。研修期間は2週間ほどで、内容は前半が講義、後半が実践（チーム開発）でした。私が担当したのは、講義パートの一部であるSQL研修です。SQLやRDBにあまり慣れていない人でも、できるだけ体系的な学びが得られるようにすることを目標に、様々な資料をまとめて提供する方針で準備しました。結果的には、ハンズオン込みで4時間ほどのやや長い講義となりましたが、勉強になったという声も頂けたのでやって良かったと思っています。 研修資料 研修内容 SQL研修の内容は、基本的には大学のデータベース講義で

Lordicon is an animated icon library with the 24,000+ premium and free animated icons, perfect for enhancing web, mobile, or content design projects.

クリーンアーキテクチャで web アプリケーションを作る際に、バリデーションはどのレイヤの責務なのか？と悩むことが多いため、それについての考察を行ってみる。 あと、バリデーションについて書いてたはずがドメインロジックとアプリケーションロジックの違いについても結構言及せざるを得ない感じになったので、そのへんの話もしてみる。 結論から言うと バリデーションはどのレイヤの責務なのか？という問い自体が間違いであり、レイヤごとにそのレイヤの責務となるバリデーションを行うべき、というのが今のところの結論。 バリデーションという単語は意味があまりに広い。「意図していないもの/ことを防ぐ」ことはすべてバリデーションと呼ばれている節がある。そのことにより、バリデーションというのはあたかも唯一つの責務であるかのように錯覚しがちだが、そうではない。クリーンアーキテクチャではレイヤによって責務を分担しているが、同

ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は、「プロダクトの開発スピードを落とさずに、かつユーザーの芯を食ったソリューションを提供するためには、すべてのスコープをいかに小さくできるかが重要」だということについて書いてみたいと思います。 ちなみに弊社はこれを実践することで開発がものすごくスムーズになり、リリース頻度が体感で 50% くらい向上しました！ スピードは失われていく前提として、プロダクトの開発スピードは意識的に改善し続けなければ、機能の追加とともに失われていきます。 提供する機能の増加に伴い、仕様の辻褄合わせだとか実装の順番だとかの複雑に関連するパラメータも同時に増えてしまうので、結果として人や時間といった必要なリソースが指数的に増えていくという話ですね。 （技術的な負債もこのパラメータに含まれ

Laravel大規模開発入門！MVC分離のFatModel問題に対する責任分離と依存管理、その設計と考え方について ナイル株式会社メディアテクノロジー事業本部の工藤さんにMVC分離のFatModel問題に対する責任分離と依存管理、その設計と考え方について解説いただきました。 こんにちは、ナイル株式会社メディアテクノロジー事業本部で開発マネージャをしています工藤@ta99toです。 今回は大規模で複雑度の高い開発をMVCフレームワークベースで構築する際に僕が課題と捉えているポイントやその具体的な解決手法について解説させていただきたいと思います。 「MVC以上の責任分離イメージがつかないよ！」 「DDDとかクリーンとかオニオンとかあのへんの設計パターンの導入モチベーションが不明」 「どうやっても最終的には複雑になって追加開発や修正開発が怖い状態になっちゃう」 ↑このような悩みを持った方に対して

素晴らしい課題でコーディング意欲を高めよう。 Photo by Ferenc Almasi on Unsplash. はじめに コーディングを上達させる最も効率的な方法の1つは、できるだけたくさん作ることです。 コーディング課題は、ものを作ることで自分のスキルアップする楽しい方法です。この記事のリストを参考に、何か選んで作り始めましょう！ 急いでいる時や、コーディングのアイディアを枯渇させたくない時は、100以上の課題をここにまとめてあります。 課題には好きなツールを使えるので、練習したいものがあれば、気軽に挑戦してみてください。 1. タスクマネージャUI なんて美しいアプリケーションでしょう！クリーンでモダン、インテリジェントなUIです。 Aysenur Turkによる「CSSグリッドを使ったタスクマネージャーUI」 学べること HTMLでCSSを使用する方法。新しいCSSグリッドを試

単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や

偏差値10の俺がい世界で知恵の勇者になれたワケ ロリバス/紺乃ユウキ あまりのバカっぷりで学校でもちょっと浮いた存在の竜一は、ひょんなことから不思議な世界に紛れ込んでしまう。だが、その世界の住人は、偏差値10と言われる竜一を“知恵の勇者”と崇めるほどの大バカ揃いだった!? 敵も味方もバカに囲まれ、竜一の世界を救う旅が今始まる！

株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 マネジメント要求定義教訓ごんおま現象依存関係ツリー思考法カオスエンジニアリングフェイルファスト技術的負債 こんにちは、羽山です。 昔話には生きる上での数多くの教訓が込められています。今回は ごんぎつね からシステム設計・開発について考えてみましょう。 ごんぎつねの話はみなさんもご存じの通り、いたずらを悔いたごんぎつねが人知れず兵十という青年に贈り物を届けるも最後まで気づかれないまま火縄銃で撃たれてしまい、最後に「ごん、お前だったのか」となる話です。 さて、 達人プログラマー という書籍には 契約による設計(Design by Contract) という考え方が解説されています。 メソッドを契約として、 要求された以上のことも以下のことも行わない という考え方

どうも、まさとらん（@0310lan）です！ 今回は、さまざまなミニクイズなどのゲームで遊びながら、実践的なWebデザインを誰でも学習できるWebサービスをご紹介します。 基本的な知識だけでなく、実際のWebサイトやアプリの画面などを活用してWebデザインに必要なスキルや感覚を自然と身につけることができるようになります。 これからWebデザインの学習を検討している人も含めて、ぜひ参考にしてみてください！ 【 Uxcel 】 ■「Uxcel」の使い方 それでは、「Uxcel」をどのように使えばいいのか詳しく見ていきましょう！ まずはサイトのトップページから【Sign Up】ボタンをクリックして無料のユーザー登録を済ませておきましょう。 メールアドレス、パスワードを設定するだけなので簡単です。 登録されたメールアドレス宛に認証用のリンクが送られてくるので、クリックして完了しておきましょう。 以

『独学大全』は、総ページ数788ページ、税込み3千円超という異色のビジネス書。17万部を突破この記事の写真をすべて見る 読書猿さんおすすめの「英文 詳説世界史WORLD HISTORY for High School」（山川出版社）。高校の世界史教科書として定評のある『詳説世界史』を英訳 読書猿さんおすすめの「解釈につよくなるための英文50」（岩波ジュニア新書）。著者は、英文学研究者で、長年英語教育に携わってきた行方昭夫東大名誉教授 自主学習のための技法を紹介した著書『独学大全』（ダイヤモンド社）が17万部を突破したブロガー・読書猿さん。現在発売中の『AERA English 2021 Spring ＆ Summer』（朝日新聞出版）で、独学で英語学習を成功させる秘訣を聞いた。抜粋して紹介する。 【写真】独学で英語を学び、海外進出を果たした俳優といえば… ＊　　＊　　＊ ■英語から逃げるこ

サーバ業務周りの管理、運用について役に立ちそうなナレッジをまとめました。 長期的に書いているため用語に統一性がなかったり、不足分など随時修正したいと思います。 1. サーバ設計 サーバスペックはどうするべき？ 使用するOSは？ CentOS開発終了について MWは何を使うべきか Webサーバ構築にはどちらを使うべき？Apache？Nginx？ サーバセキュリティで最低限押さえておきたいことは？ listenするポートは最小限にしましょう ファイアウォール設定で送受信IPアドレス、ポートの通信制御はしておきましょう 外部に出る際にはプロキシサーバを経由するようにする 随時パッチを当てるようにする linuxでのアンチウイルスソフトの検討 個人アカウントで変更系コマンドは実行させないようにする ログについて考えること ストレージ容量には気をつける データベースはどう決めたら良いか MySQLか

『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう

開発室の雑談。営業側のマネージャが言うには 「今のプロジェクトで自動テストの導入を試みている話をしたら、XXXさんのところでも過去にいくつか導入を試みたけどもみんな上手くいかなかったって話になって」 なるほど？ まあ確かに自動テストはシステム開発にとって魅惑の技法ではあるものの、では導入がうまくいっているか？　というと普及率は低いと言わざるを得ない。私がお手伝いしたプロジェクトでは、元請け側から自動テストをやるお達しが来たわけだが、紆余曲折あって掛け声倒れのような状態になってしまった。 ビジネス書の煽りタイトルのような本件だが、古式ゆかしき受注生産の業務システム開発プロジェクトに自動テストを導入しようとして失敗する事例を聞いたので、僕なりに分析して見出した要素を挙げておこうと思う。 V字モデル ソフトウェア開発の手法としてV字モデルというものがある。 オーダーメイドでシステムを作るにあたっ

clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心