タグ

programmingとProgrammingに関するakitsukadaのブックマーク (90)

  • AWS Amplify + AWS AppSyncでUnitテスト書く時のハウツー - Qiita

    Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

    AWS Amplify + AWS AppSyncでUnitテスト書く時のハウツー - Qiita
  • 【AWS Developers Meetup】RESTful APIをChaliceで紐解く

    This document discusses REST APIs and serverless computing. It provides examples of using the Chalice framework to easily create serverless REST APIs on AWS Lambda and API Gateway. Key points include how Chalice handles routing requests to Lambda functions, validates and formats responses, and allows subscribing functions to events from SNS, CloudWatch, and S3. The document also discusses using Ch

    【AWS Developers Meetup】RESTful APIをChaliceで紐解く
    akitsukada
    akitsukada 2017/12/15
    先週の AWS Developers Meetup での登壇資料が公開されました
  • サーバレスで王道Webフレームワークを使う方法

    Serverless Evolution Day in AWS Dev Day Tokyo 2017 での発表資料。 動画はこちら #=> https://www.youtube.com/watch?v=aiH8Z7MGGL0

    サーバレスで王道Webフレームワークを使う方法
  • CodeIQについてのお知らせ

    2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod

    CodeIQについてのお知らせ
    akitsukada
    akitsukada 2015/10/15
    型腕章いいなーほしいなー
  • プログラミングで変数名や関数名のネーミングに迷ったときに便利なカンニングペーパーまとめ

    僕は、プログラムをする上で変数や関数に良い名前を付けるのはとても重要と考えています。 というのも、良い名前を付ければ、それだけでそのコードがしたいことの説明になり、コメントと同等の働きをすることもあるからです。 自分がちゃんとそれをできているのかはさておき、僕は普段から、できれば読みやすくて分かりやすい名前を付けたいと思っています。他の人も読むコードであれば、できればプログラムでよく使われるような単語を利用して書いた方がより分かりやすいです。 ただ、よい名前を考えるのって、ちょっと面倒くさいんですよね。僕はこれまで、英語の辞書を利用して、考えたりしていたのですが、「何か、プログラムでよく使われる単語をまとめたものはないか?」と探したら、ドンピシャのものがいくつかあったので、それらをまとめて以下で紹介します。 photo by Michael Coté codic codic – デベロッパ

    プログラミングで変数名や関数名のネーミングに迷ったときに便利なカンニングペーパーまとめ
  • GoとMySQLを用いたジョブキューシステムを作るときに考えたこと - ゆううきブログ

    【追記】2023年3月21日 YAPC::Kyoto 2023で、ジョブキューシステムFireworqの設計と運用実績も含めて発表されました。id:tarao ++ 【加筆修正】 2020年2月16日 執筆時から6年も経過していますが、たまたまこの記事を振り返る機会があったので、日語がおかしいところを一部修正したり、一緒に取り組んだ方々の名前が書かれていなかったところを修正しました。 【追記】2017年12年24日 このエントリのジョブキュー実装がFireworqという名でOSSとして公開されました。id:tarao ++ github.com この記事ははてなエンジニアアドベントカレンダー2014の4日目です。 前回は Mackerelで採用している技術一覧とその紹介 - Hatena Developer Blog でした。 社内の開発合宿で、 id:taraoさん、id:hakobe

    GoとMySQLを用いたジョブキューシステムを作るときに考えたこと - ゆううきブログ
  • The Swift Programming Language: Redirect

    This content has moved; redirecting to the new location.

    akitsukada
    akitsukada 2014/06/03
    こっちはWeb版
  • Swift - Apple Developer

    Swift The powerful programming language that’s also easy to learn. Swift is a powerful and intuitive programming language for all Apple platforms. It’s easy to get started using Swift, with a concise-yet-expressive syntax and modern features you’ll love. Swift code is safe by design and produces software that runs lightning-fast. Modern Swift is the result of the latest research on programming lan

    Swift - Apple Developer
  • COCOAPODS SEARCH

    The iconic font designed for Bootstrap. Contains only the official font files directly from Font Awesome.

  • ジェネリックプログラミング - Wikipedia

    ジェネリック(総称あるいは汎用)プログラミング(英: generic programming)は、具体的なデータ型に直接依存しない、抽象的かつ汎用的なコード記述を可能にするコンピュータプログラミング手法である。 ジェネリックプログラミングはデータ型でコードをインスタンス化するのか、あるいはデータ型をパラメータとして渡すかということにかかわらず、同じソースコードを利用できる[1]。ジェネリックプログラミングは言語により異なる形で実装されている。ジェネリックプログラミングの機能は1970年代にCLUやAdaのような言語に搭載され、次にBETA、C++、D、Eiffel、Java、その後DECのTrellis/Owl言語などの数多くのオブジェクトベース (object-based) およびオブジェクト指向 (object-oriented) 言語に採用された。 1995年の書籍デザインパターン[

    ジェネリックプログラミング - Wikipedia
    akitsukada
    akitsukada 2014/04/08
    ウウッ “Objective-Cにあるような動的型付けを使い、必要に応じて注意深くコーディング規約を守れば、ジェネリックプログラミングのテクニックを使う必要がなくなる。”
  • 「強い型付け」「弱い型付け」って言葉を知った!

    [追記] この記事は2014年、私が文系大学生の頃、手探りでプログラミングを独学し始めた頃の記事です。温かい気持ちで見ていただけたら幸いです。 ーー !! おことわり !! このブログには、いわゆる「技術記事」は一切ありません!!!(書きたくても書けない) ただの「勉強記録ノート」です!!! プログラミング初学者の勉強記録ノートです!「日記」です!! 生暖かい目で見ていただけたらさいわいですヽ(;▽;)ノ Index “型のありがたみ”を覗く “型付けの弱い世界”を知る 動的型付けと静的型付け 型付けによる比較 “型付け”と”型変換” 強い型付けと弱い型付け まとめ 追記 (あとで読むリストなど) Introduction よくTwitterのタイムラインで「型安全」という言葉を見ます。 でも、その意味を私は全く分かっていませんでした…そもそも「型安全」という言葉は 「安全な型」を指す(だ

    「強い型付け」「弱い型付け」って言葉を知った!
    akitsukada
    akitsukada 2014/02/19
    いいまとめ
  • RubyMotion を1年以上使い続けてみての雑感 - naoyaのはてなダイアリー

    RubyMotion Advent Calendar 2013 に何か書こう、ということでエントリ。 ご存知のように iPhone アプリの HBFav は RubyMotion で作っています。Objective-C ではなく。以前は Titanium Mobile で作っていましたが、去年にバージョン2として作り直すにあたって RubyMotion に移行しました。 RubyMotion に関しては以前、以下のエントリで概要を説明しています。 RubyMotion - naoyaのはてなダイアリー それから、今年 5月に開催した RubyMotion カンファレンスのスライドなどもあります。 実践RubyMotion - Speaker Deck RubyMotion が発表されたのは 2012 年の5月 とかで、それからずっと使い続けているので1年半近くが経ったことになります。App

    RubyMotion を1年以上使い続けてみての雑感 - naoyaのはてなダイアリー
  • 若いエンジニアへ

    エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。 メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、「よい製品はよいプロセスから生まれる」ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。 物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニア仕事は計画され、コントロールされたものでなければならない。 長時間労働によって成果を生み出そうとすることも、やはり例外としなければなら

    akitsukada
    akitsukada 2013/12/04
    若いエンジニアは自覚すべきだし周囲の人間は理解しておくべきこと
  • システムテスト自動化カンファレンス2013で「スマートフォンアプリのテスト自動化をはじめよう」をお話してきました #stac2013 - やらなイカ?

    テスト自動化研究会主催のシステムテスト自動化カンファレンス2013にスタッフとして参加&モバイル枠をいただいてお話してきました。 スマートフォンアプリの テスト自動化をはじめよう from Koji Hasegawa システムテスト自動化カンファレンス2013ツイートまとめ - Togetterまとめ 毒わば皿まで 古来より「毒わば皿まで」という言葉がありまして、これはつまり「スライドを使いまわした*1ならブログエントリも使い回せばいいじゃない」という意味なのですが、さすがに心苦しいので以下オリジナルの補足をします。 尚、スライド自体もiOSに関する記述を追記したり*2、構成を見なおしたりしています。 テストレベルについての補足 途中で言った「『ユニットテストの話はするな』という圧力」はもちろん冗談なのですが、テストレベルに関して説明不足を感じたので補足します。 スライドでは「ユニ

    システムテスト自動化カンファレンス2013で「スマートフォンアプリのテスト自動化をはじめよう」をお話してきました #stac2013 - やらなイカ?
  • 多すぎる引数 - Strategic Choice

    多すぎる引数どういうこと?関数引数の理想は0(niladic:ニラディック)です。1(monadic:モナディック)、2(dyadic:ダイアディック)までは、かろうじて許容範囲です。3(triadic:トライアディック)引数は避けるべきです。4(polyadic:ポリアデイック)以上の引数は、よほどの理由がなければやめるべきです。どうして?引数は、概念上の大きな力を持っています。抽象レベルの観点で、引数と関数名は異なります。引数が現れれば、実装詳細について知る必要が出てきてしまいます。モジュールからストーリーを読み取る時点においては、「includeSetupPage(newPageContent)」よりも、「includeSetupPage()」のほうが、理解が容易です。数の多い引数は、テストの観点でも問題があります。さまざまな引数の組み合わせを網羅するテストケースは書くのは困難だから

    akitsukada
    akitsukada 2013/12/01
    オペランドの原則と併せて考えたい
  • Java 8を可能にしたJava 7の機能

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    Java 8を可能にしたJava 7の機能
    akitsukada
    akitsukada 2013/11/27
    “無料でビールが飲める,製品に対して文句を言う機会を与えられる - これらが開発者にとって無上の喜びであることは,ハイテク産業では常識となっています。”
  • 優秀なエンジニアがいなくてもやっていくために - Line 1: Error: Invalid Blog('by Esehara' )

    ITの世界には「銀の弾丸は存在しない」という合言葉がある。これはどうやら狼やドラキュラを退治するときの道具が「銀の弾」らしく、古典的な名著であり、未だに参照され続けている『人月の神話』というに収められている論文から来ているらしい。なぜ、「銀の弾丸は存在しない」と言われるのかというと、ある諸問題に関して一気に片付けられるような、そういう解決策は無い。少なくともそれらの問題に関しては泥臭く、忍耐を持って接しないといけないという話だ。川を綺麗にするためには根気よく缶を拾ったりしなければいけないのと似たようなものだろう。 元のドラキュラの話を知らないので、Wikipediaで聞きかじりに語るのだが、そもそも「銀の弾丸」といったところで、その「銀の弾丸」を使う存在というものがいる。ドラキュラの場合、それが「ヘルシング教授」である。ヘルシングといえば平野耕太の漫画を思い出すが、どうやら原作のドラキュ

    優秀なエンジニアがいなくてもやっていくために - Line 1: Error: Invalid Blog('by Esehara' )
  • 一人でコードを書きなさんな - Line 1: Error: Invalid Blog('by Esehara' )

    とりとめのない話をメモがてら。 最近、コードを読むことが多くあるのだけれども、「このコードは一人で書いているな」という感想を覚えることが多い。もちろん、基的にはコードというのは、物理的には一人で書くものであるのは間違いないのだが、たぶん、それとはまた別種のものだ。 僕がこの世界でメシをう数年前に、PHPユーザーは他の言語を知らないから、他の言語の良いプラクティスを知らないという批判が議論を呼んだことがあるようだ。このさいPHPはどうでもよく、問題は「他の言語の良いプラクティスを知らない」ということだ。プログラミング言語というのは、そのときに共存しているお互いのパラタイムと関係している。例えば、最近ならJava8がOption型を導入しようとしているのは、やはり「関数型言語」というのが成熟してきて、その方法論が有益なものとして受け止められるようになってきたからだ。C++もラムダを取り入れ

    一人でコードを書きなさんな - Line 1: Error: Invalid Blog('by Esehara' )
    akitsukada
    akitsukada 2013/10/30
    「より良く、生産的で、保守的なコードとはなにか」
  • 技術的負債を管理する

    1992年にWard Cunningham氏が、技術系ではないステークホルダにこの問題を伝えるために、初めて「技術的負債」というメタファを使いました。品質の低いコードと自動テストによるカバレッジがないことは、財務的負債と比較されます。このようなコードは、開発者だけでなく、すべてのステークホルダが負う財政的な重荷になり、将来的に利息が課される負債になります。元額は、コードベースを将来簡単に変更できるようにリファクタリングするコストです。利息は、チームがよいコードではなく、汚いコードに取り組まなければならない場合に、将来支払う余分なコストです。 財務的負債とは違い、技術的負債は返済しなくてもよい負債です。時には、返済するのが無駄なこともあります。ある部分のコードを読んだり、変更したりすることはめったにないか、決して起こらないかもしれません。そのため、技術的負債も、どのくらい起きそうかを考慮す

    技術的負債を管理する
  • プログラマーは皆、常に秘密や嘘を抱えている - totopon114689の日記

    プログラマーは皆、常に秘密や嘘を抱えている。 これは間違いない。 基的には誰にも話さないが、 (家族や友人などプログラムを知っていない人間に話しても分からない、という事もある) プログラマー同士の飲みの席などで、過去の笑い話として酒の肴になる事はある。 秘密や嘘の傾向には幾つかのパターンがある。 1) 仕様があいまいな場合の適当なコーディング 仕様があいまいな機能を実装する場合、想定していたものよりもプログラム量が膨大になる事はよくある。 また、細かいパターンや想定外のケースに対し、どのようにプログラム的対処を行うべきか? 洗い出しているとキリがない場合もある。 仮に事前に洗い出していたとしても、 「ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか?」 などといった、その先がまたあいまいになっている場合もある。 このような場合、来であれば決裁権のある人間に

    プログラマーは皆、常に秘密や嘘を抱えている - totopon114689の日記
    akitsukada
    akitsukada 2013/05/23
    ぶひー/ このような秘密や嘘が発生する一番の理由は、たいていの場合、その現場の体制にある。 プログラマーが隠し事をする一番のモチベーションは ・ストレスであり ・窮屈な環境であり ・疎遠な人間関係 なのである