いい加減シェルスクリプトで [ $? -eq 0 ] や [ $? -ne 0 ] なんて エラー処理を書くのはやめよう！ - Qiita
いい加減シェルスクリプトで [ $? -eq 0 ] や [ $? -ne 0 ] なんて エラー処理を書くのはやめよう！ShellScriptBashLinuxUNIXmacOS はじめに [ $? -eq 0 ] や [ $? -ne 0 ] は冗長でデメリットしかありません。非常に多く見かける書き方ですが、1979 年に Bourne シェルが広く公開された時からこのようなコードは必要なく、実際に当時は使われていませんでした。このような書き方をしなければならなかった歴史的な経緯などはありません。これはなぜか広まってしまった良くない書き方です。良い書き方は最短の時間と最小の手間で目的を達成します。 優れたコードとは無駄がないコードです。丁寧なコードとは無駄な処理を書くことではありません。優れた文法を持つシェルは短いコードで正しく動作します。[ $? -eq 0 ] や [ $? -ne
![いい加減シェルスクリプトで [ $? -eq 0 ] や [ $? -ne 0 ] なんて エラー処理を書くのはやめよう！ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/4e42d360866a8ef193de27e43e50492da34de08d/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JUUzJTgxJTg0JUUzJTgxJTg0JUU1JThBJUEwJUU2JUI4JTlCJUUzJTgyJUI3JUUzJTgyJUE3JUUzJTgzJUFCJUUzJTgyJUI5JUUzJTgyJUFGJUUzJTgzJUFBJUUzJTgzJTk3JUUzJTgzJTg4JUUzJTgxJUE3JTIwJTVCJTIwJTI0JTNGJTIwLWVxJTIwMCUyMCU1RCUyMCVFMyU4MiU4NCUyMCU1QiUyMCUyNCUzRiUyMC1uZSUyMDAlMjAlNUQlMjAlRTMlODElQUElRTMlODIlOTMlRTMlODElQTYlMjAlRTMlODIlQTglRTMlODMlQTklRTMlODMlQkMlRTUlODclQTYlRTclOTAlODYlRTMlODIlOTIlRTYlOUIlQjglRTMlODElOEYlRTMlODElQUUlRTMlODElQUYlRTMlODIlODQlRTMlODIlODElRTMlODIlODglRTMlODElODYlRUYlQkMlODEmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWZhZDdkMjVkYjUxODQ5OWRhZDhiZWM3ZGMwN2ZlY2Q0%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBrbzFua3NtJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0zNDA2OWFjMTI5MDIyYmE1ZjY0OTI5ZGU2ZGUwNDU5Zg%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D8f12358d68288246128c01d35bcfa4b1)
いつか起業したいエンジニアへ - Qiita
はじめに 34 歳のとき、勤めていた会社の経営が傾き早期退職を促されたのを契機に独立しました。その後、41 歳で Authleteオースリート 社を設立しました。諸般の事情で現在も Authlete 社の代表取締役という肩書きを持っていますが、経営者的な仕事は他の人に任せ (参照: シリコンバレーのプロフェッショナル CEO を迎えて米国市場に挑戦する日本のスタートアップの話)、50 歳目前の現在もプログラマとしてコードを書き続けています。 Authlete 社設立 (2015 年 9 月) から 8 年半弱経過したものの、まだまだ小さな会社で道半ばであるため、起業家として何か語るのは時期尚早ではあるものの、軽い体調不良が長引く中、『自分のエンジニアとしてキャリアを振り返ろう！』という記事投稿キャンペーンを見かけ、生きているうちに子供世代のエンジニアの方々に何か書き残しておこうと思い、文章
パイプに関係するさまざまなバッファ、ちゃんと意識していますか？ - Qiita
はじめに コマンドをパイプでつなげた時、各コマンドの間にはいくつかのバッファが存在します。そのバッファについてちゃんと意識しているでしょうか？ バッファの存在によって各コマンドの実行には分かりづらい変化があります。そのバッファを知らないと罠にハマってしまう・・・かもしれません。 プロセス間のパイプ通信のバッファ まずプロセス間のパイプ通信に存在しているバッファです。多くのコマンドは行単位でデータを処理しますが、一般的にパイプでつなげた各コマンドはそれぞれ処理速度が異なります。処理がすぐに終わるコマンドもあれば時間がかかるコマンドもあります。各コマンドは並列で動作可能ですが必ずしも並列で動作するわけではありません。 一般論としてパイプライン全体の処理にかかる実時間はパイプでつながったコマンドの中で一番遅いコマンドに足を引っ張られます。いくら並列で動作可能と言ってもデータが到着しなければ処理す
文章中に<br>タグ入れるのやめてください - Qiita
はじめに 文章中に改行で<br>入れるのやめてください これは各種CMSにお願いしたいことです。テキスト投稿サイトでも同じです。 スクリーンリーダーで読み上げた時にめちゃくちゃ読みづらくなるからです。 なぜか スクリーンリーダーは基本はキーボードで操作します。タグ内に文字が書いてあれば、それを読み上げてくれます。しかし、<br>タグがあると、そこで一旦文章が途切れます。MacのVoiceOverの場合、「空のグループ」と読まれます。もしそのまま<p>タグ続きであれば、段落続きで連続で読み続けることができます。しかし、<br>が改行目的で使われていると、その度に「空のグループ」と読まれます。これがブログサイトや小説投稿サイトなどの文章メインのサイトだと、スクリーンリーダーを使うユーザーにとってはUXが最悪です。 プログラミングは、コンピュータに特定のタスクを実行させるための手段です。 コンピ
Gradleでコンパイル警告を100件より多く表示する - Qiita
背景 コンパイル警告があまりに多いプロジェクトだと、最初の100件までしか警告内容が出力されない。そもそもコンパイル警告が多い状態で放置していること自体が問題だが、途中で省略させずにすべてを確認したいこともある。 $ ./gradlew clean build Starting a Gradle Daemon (subsequent builds will be faster) ... ノート:一部の入力ファイルは推奨されないAPIを追加使用またはオーバーライドしています。 ノート:入力ファイルの操作のうち、未チェックまたは安全ではないものがあります。 ノート:詳細は、-Xlint:uncheckedオプションを指定して再コンパイルしてください。 警告100個
【ネタ】コメントだけしか書いていないのに「Hello, world!」と表示されるJavaプログラム - Qiita
これはJavaでポインタで使えるというネタから着想を得たプログラミングネタです。 厳密には 「コメントだけ書いてあるようにしか見えない」 です。 コメントだけしか書いていないのに「Hello, world!」と表示されるJavaプログラム % java --version openjdk 16.0.2 2021-07-20 OpenJDK Runtime Environment Microsoft-25298 (build 16.0.2+7) OpenJDK 64-Bit Server VM Microsoft-25298 (build 16.0.2+7, mixed mode) import java.util.*; public class Main { public static void main(String[] args) throws Exception { //\u000a
ChatGPTが凄いのは究極に心理的安全性が保たれているから - Qiita
だいぶ今更感あるけどchatgptが凄いですね。 僕も使わせてもらってるんですけど革命的だなと感じています。 特にプログラミング領域ではほんとに強力です。 使っていくうちに、AI技術云々よりもやはり僕らが求めたのは心理的安全性だったんだ。と再認識することになったのでそれについてお話させてください。 Chatgptが素晴らしいのはどんな質問しても怒られないから 今いる職場にだって聞けば優しく答えてくれる先輩や諸賢はたくさんいると思います。 そして、そういう素敵な職場だと会社としてもチームとしても「心理的安全性は大事だ」という風潮はあると思います。 ※ここでいう「心理的安全性」というのは、どんな発言をしても許される、尊重される、傷つかない。といった意味で扱います。 そんな素敵な現場だったとしても、 「ローカルからGAのAPIを叩いてデータを取得したいけどどうすればいいですか」 この質問ってなか
GitHubに彩りを - Qiita
この記事を書いた理由 業務はもちろん、個人学習でもGitを使用される方は多いと思います。 ふとGitHubを見た時にって思うことありませんか？？ （私は過去のリポジトリを見ると思います笑） そんな中、今年コミュニティで開催されたハッカソンでメンバーから共有していただいた【gitmoji】を活用して どのように変わったのか、感じたことをまとめようかと思います。 （学習意欲向上に繋がれば幸いです） 目次 gitmojiって？ gitmojiを導入してみよう！ アイコンの種類について 使用してみた感想 纏め gitmojiって？ gitのコミットメッセージを装飾する（アイコン？がつきます）ことができて、 コミットの内容が視覚的にわかりやすくなります！ gitmoji公式サイト gitmojiを導入、使ってみよう 簡単にパッケージでインストールして使ってみましょう。 npm i -g gitmoj
【Github】プルリクエストを出した後に ドラフトに変更する - Qiita
はじめに 間違えて普通のプルリクエストをだしたときに、（当時のバージョンでは）プルリクエストからドラフトに変更できないよって記事をみて焦ったので。。 GitHub公式ページ（日本語）はこちら>> 本題 まず、プルリクエストをだしました。 Openになっていて、マージもできる状態なので普通のプルリクエストですね。。 あれ。。。右の方に。。。。 ありました。まだ途中かい？ドラフトにするか！みたいなことが書いてありますね。 Convert to draft をクリックしました。 Convert to draft をクリック よかったです。Draftになってます。 おまけ おまけというほどでもないですが。。。 draft <=> open は何度でもできるようです。
RictyフォントとRicty Diminishedフォントが正式にサポート終了となった話 - Qiita
2023年1月現在、Qiitaのコードブロックでも採用されている有名な日本語対応プログラミング用フォントのRictyとRicty Diminishedが、2023年1月28日をもって「正式に」サポート終了しました。具体的には、配布ページの冒頭に、以下の文章が追加されています。 Ricty および Ricty Diminished は、2010 年代前半には欧文・和文合成プログラミング用フォントとして先駆的でしたが、現在は前時代的な存在となっています。不具合もいくつか確認されています。良質なプログラミング用フォントが数多く登場していますので、それらの利用をおすすめします。 よって今後は、他のフォントを使用するのが良いでしょう。 移行先の候補となるフォントの一覧もあるので、ぜひ確認してみてください。 経緯 RictyフォントとRicty Diminishedフォントは、プログラミング用フォント
なぜライセンスを改造しちゃいけないの？ - Qiita
もしあなたが書いたプログラム／ソースコードを、「オープンソース」または「フリーソフトウェア」として他者から 自由に 使ってもらうことを意図してるなら、やるべきではない。 注意 この記事を書いてるひとは法律の専門家じゃないよ。詳しいことはべんごし・べんりしなどのせんせいに相談してね。 そもそもライセンスとは 許可とか免許とかそんな感じの意味ですが、オープンソースライセンスを「利用許諾契約書」として解釈するには不可解な点があります。 実際には配布元(作者)から受け取った人への「お約束」だと解釈するべきです。つまり、ライセンスによって提示する条件を守る限りは複製権・頒布権・同一性保持権・公衆送信権の侵害について刑事告訴および利用差し止め、損害賠償請求などの提訴を行ふことはない、といふ約束です。 現行(2016年4月)の日本の法律において、著作権法違反は親告罪——つまり権利者の告訴がなければ刑事裁
ちょっとユニークなライセンスたち・まとめ - Qiita
※タイトルから「オープンソースライセンス」を消しました。ライセンス分類はGentooグループの License Groups レジストリによります。 NYSL 分類: 未掲載 日本人にはお馴染みのライセンス。2016年4月現在、400以上のプロジェクトで採用されている。 A. 本ソフトウェアは Everyone'sWare です。このソフトを手にした一人一人が、 ご自分の作ったものを扱うのと同じように、自由に利用することが出来ます。 A-1. フリーウェアです。作者からは使用料等を要求しません。 A-2. 有料無料や媒体の如何を問わず、自由に転載・再配布できます。 A-3. いかなる種類の 改変・他プログラムでの利用 を行っても構いません。 A-4. 変更したものや部分的に使用したものは、あなたのものになります。 公開する場合は、あなたの名前の下で行って下さい。 B. このソフトを利用する
糞コードは直すな。 - Qiita
とりあえず落ち着け。 みなさん、毎日なにかしらのコードを読み、開発する日々を送っていると思います。そんな中で、 糞コードは死ぬべきである！！絶対に直すべき！！ という感情に取りつかれてしまうことがあると思います。自分の技術力に自信のある人ほど、無理やりにでも直そうと試みると思います。それがどんな修羅の道か。そして、糞コード修正がどんな道を歩むのか。この記事では糞コード修正の罠とありがちなストーリーについて書きたいと思います。 ビジネスとしてのプログラムは本質的に糞である 例えば、「携帯電話の利用料金」のプログラムがあります。 「携帯電話 透明性高め料金値下げを」という記事もあるように世の中の携帯電話の料金プランはかなり複雑です。例えば、auだと「auでんき」といった電気料金とパックされた電話料金プランがあります。また、「auスマートバリュー」といったプランもあり、家のインターネット回線をa
google-home-notifierの代替となりそうなgoogle-home-playerを試してみる - Qiita
はじめに Google Home発売当初、Google HomeハックのHello Worldとも言える「Google Homeを喋らせてみた」ハックで誰もが使用したであろう「google-home-notifier」ですが、動かなくなったりメンテされなくなったりで、もはや多くの方がGoogle Homeを喋らせることをやめてしまったのではないでしょうか。 そんな折ふとnpmを眺めていたら「google-home-player」というパッケージがあり、READMEでもgoogle-home-notifierの代替とあったので試してみました。 google-home-notifierはcallback形式の書き方でしたが、google-home-playerはPromiseで書けます。もちろんasync/awaitでも。 そのおかげもあってかgoogle-home-notifierに比べ大分
シェルスクリプトで安全簡単な二重起動防止・排他/共有ロックの徹底解説 - Qiita
はじめに シェルスクリプトで二重起動防止やロックをする方法を検索すると、いろいろな方法や書き方が見つかりますが、どれを使えばよいのか、本当に正しく動くのか、不安になりますよね？ ディレクトリ (mkdir) やシンボリックリンク (ln) を使った独自実装の例も見かけますが、エラー発生時や予期せぬ電源断、CTRL+C で止めたときなどでも問題は発生しないのでしょうか？ まず、ディレクトリやシンボリックリンクを使った独自実装はしない。これを肝に銘じてください。シェルスクリプトでのロック管理はとても難しく、一般的な排他制御の知識に加えて、シェルスクリプト特有の問題、シグナルやトラップ、サブシェルや子プロセスの問題、さらには特定のシェル固有の仕様やバグなどさまざまな問題に対処する必要があり大変です。独自実装の例では古いロックファイルが残ってしまい、それをいつどのタイミングで片付ければ安全なのか？
知ってますか？ :shipit: の意味と由来 - Qiita
これは何？ → GitHub でよく使われる絵文字の一つです。 :shipit : というコードが割り当てられていて、"ship it" と読みます。 若干わかりづらいですが、「帽子をかぶった（動物の）リス」です。 どういう意味？ 一般に、PR に対するレビューコメントにおいて良く使われます。 「変更に問題はない、コードをリリース（ship）してしまって構わない」という意味です。 また、最近ではコミットメッセージにおいて見かけることが増えています。 「 vX.Y.Z」として、このコミットを契機にパッケージをリリースするようなケースで利用されます。 なぜリスなのか？ リス自体に意味はありません。 GitHub 所属の @jglovier さんが、Quora 上でその由来について言及しています。 On GitHub, what is the significance of the 'Ship
getoptsを関数（function）の中で使う - Qiita
基数変換について調べた https://qiita.com/macoril/items/77ba050cad17f03ed46a ついでに基数変換用のエイリアスを設定しようとして詰まった。 TL;DR functionの中でgetoptsを使いたいときは OPTやOPTINDなどの変数をlocalで宣言しないといけない 詳細 # copy to your bash_profile or somewhere you write aliases, # then you can convert a number to different base by cbase # エイリアスを設定しているあたりにでも以下のコードをコピペすると基数変換がcbaseコマンドで簡単できるようになります function cbase() { function echo_usage() { cat << USAGE
Groovyを知らない人のためのbuild.gradle読み書き入門 - Qiita
これは、 G* Advent Calendarの15日目の記事です。 昨日は @int128 さんの Gradle Slashプラグインをリリースしました #gadvent でした。 明日は @tyama さんです。 はじめに Gradle 便利ですよね。便利すぎて Ant や Maven には戻れないです。 なにが良いって、設定ファイルである build.gradle の記述量が、 Ant の build.xml や Maven の pom.xml と比べると非常に少なくて済むのが良いです。 build.gradle は、設定ファイルと言いつつも、その実体は Groovy で書かれたスクリプトファイルです。 Gradle は、 Groovy の持つメタプログラミング機能や省略記法などを利用して、設定を簡潔に記述できるようになっています。 これはメリットなのですが、一方で Groovy の
メソッド上にコードの複雑さを表示するVisual Studio拡張機能を作りました - Qiita
ソースコードの複雑さ、不具合のリスクを定量化したコードメトリクス1というものがあります。 コードメトリクスは計算方法によっていくつか種類があり、メジャーなものだと以下のものがあります。 Cyclomatic Complexity（循環的複雑度） Cognitive Complexity（認知的複雑度） Maintainability Index（保守容易性指数） Lines of Code（コードの行数） これらのコードメトリクスを計算し、CodeLensに表示するVisual Studio拡張機能2を作成しました。 tackme31/howmessy: How messy is your code? 以下のようにコードメトリクスをもとにコードが複雑かどうかを判定し、CodeLensに表示してくれます（デフォルトではCognitive Complexityをもとに計算します）。 今のところ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【CSS】子要素が特定の数の場合にのみスタイルを適用する方法 - Qiita
