Introduction Webエンジニアであれば、「自分達の手で0から作ったプロダクトで世の中を変えられたらな、それで食べてけたらなー」と夢見ることがあるのではないでしょうか。 私たちは、夫婦2人で、プライベートの時間でアプリ開発と運営をしています。その過程でぶつかった壁がとてもたくさんありました。 全てのプロダクトで当てはまることではなく、あくまでも特定のケースなのでなかなか一般的な手法として展開しずらい事例が多いですが、これらの困った体験が何かのお役に立てればと思い書きました。 実際に起こったこともあれば、起こってはないが、経験から推測するとこのケースはこう対処すればいいのかもしれないと思ったこと、の両者を記載しています。本やブログなどで得た知識をそのまま紹介するというよりは、実体験に基づいた内容になっています。 人が集まるまで 作る時間が無い 困った たくさん機能開発したいが、普段

Django Girls Tutorial について Djangoに入門して、まず当惑するのが初心者向け日本語情報の少なさです。 Djangoは一応公式のチュートリアルがあります。 これが非常に読みにくいです。専門用語が多く、LinuxやPython、他のフレームワークに習熟していてなんとか理解できるレベルで、初学者の心を折るには十分です。 それよりも、はじめの一歩として優秀なのが Django Girls Tutorialです。 Django Girls Tutorial 名前の通り、アメリカのPythonコミュニティで定期的に開いている女性を対象としたワークショップで、教科書として利用しているものを翻訳したものです。 明快な文章で、内容も丁寧に段階を踏んでいます。 なにしろ最初の項目が「インターネットの仕組み」です。そこからウェブサーバの仕組み、Pythonのインストール、テキストエデ

Webのセキュリティ プログラミングスクールからエンジニアデビューしたものですが、セキュリティの重要さと、攻撃された時の恐ろしさに戦々恐々としました。今でもしてます。 たとえ、エンジニアでなくとも、最低限の対策をしないとリリースするのは危険です。 プログラミングスクールではセキュリティについては、深く学ぶことはあまりないと思います。 自分と同じ駆け出しエンジニアさんや、エンジニアじゃないけど、Webサービスリリースしたい！みたいな方に共有できたらと思います。 セミナーでセキュリティについて学んできたので、復習も兼ねて自分なりの解釈で記事に落とそうと思います。 脆弱性? Webサイトの脆弱性は二種類。 ロジックエラー(設計段階で生まれる脆弱性) セッションの管理不備や特殊文字を処理せずにデータを受け渡してしまうことです。 テクニカルエラー(実装段階で生まれる脆弱性) SQLインジェクション、

Linux サーバでの「Too many open files」エラー対策について調べたのでまとめてみました。 確認した OS は CentOS 5.9 と CentOS 6.3 です。 「Too many open files」は Linux でプロセスが開けるファイルディスクリプタの上限に達してしまうと発生するエラーです。 「ファイルディスクリプタ」という名前ですが、 Linux ではソケットもファイルディスクリプタなので、ファイルを開いた場合だけでなく、ソケットを使って通信を行う場合にもファイルディスクリプタが使用されます。 そのため、Apache や Tomcat などで高負荷なサイトを運用している場合などには、比較的遭遇する確率の高いエラーではないでしょうか。 このエラーを回避するため、プロセスがオープンできるファイルディスクリプタの上限を変更します。 まずは以下のコマンドを実行

まず ＊ ProgateやTechAcademyに対する広告でもなければ宣伝でもないです ＊ 最近流行りのポエム記事です ＊ 長いです。言いたいことは最後のまとめに書いてあります ＊ 同じような職を未経験で進む人が今後増えると思うので参考程度に読んでいただけたら幸いです きっかけ 一浪し某マンモス大学理工学部に入学、２年次に中退 いわゆるただのクズになり、大学に行かなくなった 大学を辞めた後はアルバイトをし、親に金を返しながら将来のことも考えず生活していた そんなある日、私はある程度貯めた金でmacbookairを購入(かっこつけたい一心で) こんな適当な思いが、プログラムというものとの出会いきっかけになった プログラミングとの出会い macbookの初期設定をしていると ふと、フォルダの中にクソサイズがでかいアプリを見つける 「Xcode」 だ ナンダコレハと調べてみるとどうやらipho

2024年7月12日に開催された「try! Swift Tokyo WWDC Recap 2024」にて、「Core MLのアップデート」と題して登壇させていただきました。 発表資料はこちら： www.docswell.com 記事として再構成したものがこちら（スライド版よりこちらのほうがオススメです）： zenn.dev 会場はなんとApple JapanのCaffè Macs。 https://x.com/toyochang/status/1811674746838483273 発表中の様子 1 https://x.com/toyochang/status/1811677924736848178 https://x.com/toyochang/status/1811680791614881973 参加人数70名以上とオフライン発表としてはカンファレンス並みの規模／try! Swiftプ

前回のコンピュータ業界でよく出る英語に続きリスニング&スピーキング編です。 こちらもよろしく^^ TOEIC900でも英語が話せない日本人へ。まだワンチャンあるよ 頭がいい人ほど英語が話せない理由 なぜ日本人はTOEIC900点でも英語が話せないのか？ さて、2020年から小中学校の英語教育が強化されます。 今後、英語が得意な若手エンジニアが増えてくるでしょう。 人手不足、特に機械学習エンジニア不足のため 外国人エンジニアの受け入れやオフショア開発も増えそうです。 Qiitaはプログラミングに関するブログをとのことですが 今や英語力無くして機械学習、ブロックチェーンなどの最先端技術を 習得することはメモ帳でプログラミングするに等しくとても非効率です。 つまり良いプログラマは英語をうまく使いこなすのです。 英語力がないと、適切なメソッド名やコメントを書くこともできなければ読むことも出来ません

配色を決めるのは難しい ブロガーの皆さんはカスタマイズをとかすると思うんですが、配色ってどうやって決めていますか？いい感じの色使いって難しいんですよね。そういう仕事してるぼくでさえ、悩むポイント。ちょっと苦手です。 今日紹介するのは配色ツール。 このブログの場合は自分の好きな色でまとめた感じなんですけど、やはり見やすい色の組み合わせってあるので、好きな色をいくつも入れたら見た目がド派手になってしまった！なんてことも起こりがち。 そういうのを一気に解決してくれるやつを紹介します！ AI（人工知能）です！未来ですね。 しかも無料！（素晴らしい） Khromaっていいます！！（読めねーよ！） Khroma – The AI color tool for designers 使い方はとても簡単 サイトを開いて【Personalize】をクリック するとカラーパレットがズラッと出てくるので好きな色を

はじめに この記事は間違って、あるいは騙されてSIerに入ってしまったピュアな若手社員と、就職先がそこしかない残念な学生に向けた、取っておくべき資格を羅列するものです。 コンピュータサイエンスのマスターコースを修了し、外資系ベンチャーの研究・開発職で働いている方のための記事ではないです。 TOEIC ・ここから入るあたりでお察しください。 ・海外ビジネスやオフショアなどを行う上流のSIerで求められる資格 ・といってもせいぜい500点くらい ・TOEICで英語が身に付くかという問題はあるが、英語ができる人はTOEICもできる 基本情報技術者 ・「文系エンジニア」という二言で矛盾する奇妙な人間を育成するのには必須の資格 ・業界用語を暗記する程度の役に立つ ・情報系学部の教養科目レベルなので、情報系は学生のうちに取る 応用情報技術者 ・基本情報技術者を取って入社した人が報奨金をもらうための資格

SwiftUI is a modern way to declare user interfaces for any Apple platform. Create beautiful, dynamic apps faster than ever before.

どうも。よくブロックチェーン興味あるけどよくわからん、という声を某所から聞くので、僭越ながら自分が勉強するために使っている参考文献を紹介します。 今後自分が新しく読むたびに追加していく予定です。 色々と追加していって、だんだん初心者向けじゃなくなっている気がしますが、各通貨内の小見出しが、上から下に行くに従って内容が難しくなるように並べてあります。 Mastering Bitcoin (書籍) Mastering Bitcoin Mastering Bitcoin（翻訳版） https://bitcoinbook.info/translations-of-mastering-bitcoin 名著中の名著ですね。主にビットコインのブロックチェーンに関する一通りの説明が乗っています。業界では読んでいることが常識と呼ばれるくらいに一般的な書籍となっています。 全部目を通しておいて損はないと思われ

人格否定する人とは、相手の人間性や性格などを真っ向から否定する人のことです。 相手を避難するといった生易しいものではなく、その人の存在そのものを否定するので、滅多にそんなことをする人はいません。 しかし、実際に人格否定する人がいるのはあなたもご存知でしょう。 では、なぜ人格否定する人がいるのか。 そこで今回は人格否定する人の心理についてご紹介していきますので、ぜひあなたやあなたの周りの人に当てはまるかどうか確認しながら最後まで御覧ください。 人格否定する人の心理 嗜虐心が強い ふつうの人は、相手に対して強い不快な感情を抱いて相手を責めるときでも、人格までを否定しようとはしません。 たとえ、人格を否定するような言葉が頭に浮かんでも、「そこまで責めるのはかわいそうだ」という気持ちになり、自制をするのがふつうでしょう。 人格否定する人は、そうした心理を抱くことはありません。 それは、「人がかわい

こんにちは。10分で生産的なミーティングができるWeb会議ツール「minmeeting」を開発している伊勢川です。 minmeetingはすべて在宅ワークで開発を進めてきました。その開発の中で、いろいろ試行錯誤をしながら、在宅でもそれなりの生産性が維持できるようになってきました。 そこで、今回はITエンジニアが週末在宅ワークをする際に、生産性を上げるための工夫を、5つの観点から整理してそれぞれ紹介していきます。 時間の使い方をコントロールする 週末在宅ワークの鍵となるのが、いかに時間を確保するのかということです。ここでは、その時間の確保のための工夫を紹介します。 週に20時間以上を確保する 少し古いITエンジニアの勉強時間の時間の調査1によると、大半が週に3時間未満というデータがありますが、プログラミング能力を競うサイトの調査2では、11%の人が週20時間以上勉強や個人の開発に費やしている

3ヶ月間ブログ休んでましたが、 まぁそういうこともあるよね。 大事なことは続けることだと思いますんで、グッと面の皮を厚くして今まで通りいきますね。 さて、 色々な求人媒体様ならびにFBでもさかんに言ってますが、 RoomClipのエンジニア大募集中でございます。 iOS、Android、サーバサイド、インフラ、UI/UX、 全方位に人材不足なので、どの方面から始めても、どの方面にも成長できます。 そして「俺ならもっとすごいのつくれるのに！」と思っいながらも、 日々決められたフレームワークで開発せざるを得ない敏腕エンジニアの方。 ぜひウチで腕試しにいらっしゃってください。 バチバチしましょう。 とにかく、少しでも興味ある人は、このブログへのコメントでもなんでも結構ですので、 ご連絡下さいませ。「ちょっと話してみたいんだけど」的なノリも大歓迎です。 Wantedlyさまからも募集要項だしており

3. 自己紹介 - まぁまぁ MySQL でご飯食べてます - 一時期は Resource Monitoring や KVS にも 力入れてました - ネットワーク的には素人です - Linuxとハードウェアは嗜む程度 - disk I/O にはむかしから興味あります - その他 slideshare はこちら - http://www.slideshare.net/takanorisejima/ 4. 本日のお題 - kernel 新しくしたりすると、TCP的に意識したほ うが良い変化が見つかるので - 今日は、Webアプリケーションサーバの観点か ら、 connect(2) する際に気になる TIME_WAIT について、書いてみようかと思います - 有識者からのマサカリを、強く歓迎いたします 5. 最初に参考資料 - この二つの記事を読んでいただけば、それで概 ね良いと思うんですが

(↓間違いの訂正アリ↓)第4回大阪MySQL勉強会資料 06/03 修正 ◆@y_catch さん @yoku0825 さんに教えていただいた誤謬の修正 ・「使用権」は誤解を招くと教えていただいたので "「使用」と「利用」""ライセンスの２つの法的根拠"などを修正 また、使用が権利でないことの理解の一助となるよう "「使用」と「利用」とライセンス"のページを追加 ・GPLのバージョンについての情報を追加して、用語はGPLv2へ統一(したつもり) ・"MySQLの著作権"について、教えていただいた情報を元に修正 ◆また、以下も修正 ・発表直前に書き上げたため、推敲せず話の繋ぎがうまくいってない箇所や 分かりにくい説明、見にくいところなどを修正 ・[GNUによる4つの自由]で自由の保障で勘違いしてたところを削除 ・オープンソースライセンスの定義を正しいものに修正 ・時間がなくて機械翻訳のままだ