Android開発をする上で知っておいてほしいなと思うこと - こやまカニ大好き
現在の Android Developers の情報は非常に充実していて、Developer Guides を順に読み進んでいくだけで開発に必要な知識とGoogleが想定している(であろう)最も基本的な実装を学ぶことができる。 特にこの「基本的な実装」というものが重要で、これを知っておかないと開発者間の意思疎通がスムーズに行えなかったり、そもそも気をつけておくべき注意点を見落としがちになってしまう。 とはいえ、今の膨大な公式ドキュメントをただ読めというのは厳しいので、Android開発をする上で最低限理解しておいてほしい(と僕が思っている)事柄と、それについて知ることができるドキュメント類についてまとめてみることにする。 2018/03/25 : リリース周りについて別記事に追記した。 nein37.hatenablog.com 公式ドキュメントの重要ページ 公式ドキュメントと言った場合、
Zoho Creator と kintone の比較
きっかけ 中小企業が自分達で業務システムを作れると良さそう 地方の中小企業のIT化をサポートする仕事とか出来ないかと、何となく考えていて、過去に何回かブログで触れました。（「 何に特化するか」、「商工会議所に加入しました」） 1つの方向性として、地方の中小企業がSIerに丸投げするのではなく、自分達で主体的に（必要に応じてSIerをうまく利用して）業務アプリを作れるようになると良いと考え、そういうののサポートをしたいと考えていました。 具体的には、単なるシステム導入だけでなく、IT化に関するトレーニングなども実施していければと考えていました。 それ、 kintone なら出来るよ そうした中、プログラムの知識がほぼ不要で業務アプリを作れる kintone の存在を知りました（というか思い出しました）。 幸運なことに、たまたま、周りに kintone に非常に詳しい人物がいて、その人から長所
ローコード開発の決定版ガイド｜ビルドシステム×Mendix
ローコードとは何か？ ローコードとは、コーディングをテキストからビジュアルに昇華させるアプリケーション開発手法である。 技術的なコーディング環境ではなく、ローコードはモデル駆動型のドラッグ＆ドロップ・インターフェースで動作します。プロの開発者、初心者の開発者、サブジェクト・マター・エキスパート、ビジネス利害関係者、意思決定者など、あらゆる開発スキル・レベルの人が、ローコードを使用して価値主導型のエンタープライズ・ビジネス・アプリケーションを構築できます。 ※さらなる可能性を見る ローコードの特徴と利点 ローコード・アプリケーション開発プラットフォーム（LCAP）は、アプリケーション・ライフサイクルのあらゆるステップを抽象化し、自動化する。 開発プロセスを加速する機能により、技術的な専門知識を持たないユーザーでも開発にアクセスしやすくなります。 ビジュアル・モデリング ドラッグ＆ドロップ機能
Best Low-Code Development Platforms Software in 2020 | G2
Low-Code Development Platforms reviews by real, verified users. Find unbiased ratings on user satisfaction, features, and price based on the most reviews available anywhere. Low-code development platforms provide development environments that allow businesses to develop software quickly with minimal coding, reducing the need for extensive coding experience. The platforms provide base-level code, s
プログラマーとは誰か - かみなが れお
ちょっと書き殴りが流石に酷すぎたので後日いろいろ整えます はじめに 「プログラムはこうして作られる プログラマの頭の中をのぞいてみよう」を読みました プログラムはこうして作られるプログラマの頭の中をのぞいてみよう 作者: 平山尚(株式会社セガ) 出版社/メーカー: 秀和システム 発売日: 2013/09/25 メディア: 単行本 この商品を含むブログ (5件) を見る 普段はUnityでC#かいてる。業務でも。ほかの言語まともにさわったことない ちゃんと言語の勉強したことないし、プログラムの考え方がしりたいなといってたらizmさんから教えてもらったので読み始めた。 紹介していただいてありがとうございます。 本の名前で検索をかけるといろいろ書評は出てくるが、自分の頭の整理のためにもどのような本か、かいておきたい。 全くプログラムを書いたことがないひとのために書かれたほんで、作者が作った言語を
プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!
今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ
GraphQLを使ったアプリケーションがリリースされたので勘所を考えた - Feedforce Developer Blog
小飼です。Dropbox上場のニュースをみて『Rustで上場』という標語を考えたんですが、ロジックが乱暴過ぎるとの評価を頂きました。 さて、フィードフォースでは去る3月8日広告出稿・運用支援ツール『EC Booster』をリリースしました。 この新サービスにはクライアント・サーバ間コミュニケーションのインターフェースにGraphQLを採用しています。 GitHub, Apolloなど、海外では採用事例の増えてきている印象のあるGraphQLですが、国内における採用事例はまだあまり多くはないようです。 そこで本稿では、フィードフォースで実際のプロダクションに採用してみての、初期の使用感などをお伝えしたいと思います。 なお、本アプリケーションはAPIサーバ及びアセット配信サーバとしてのRailsアプリケーションが、 React/Apolloで構築されたクライアント側アプリケーションと、Grap
C# で Single Page Web Application が書ける Blazor が凄かった件 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Blazor との出会い 今年2018年2月7日に、自分のソーシャルネットワークのタイムラインに Microsoft のブログ記事が流れてきました。 A new experiment: Browser-based web apps with .NET and Blazor ブラウザベースの .NET による Web アプリフレームワーク、"Blazor" (ブレイザー) だそうです。 これを読んだ当時、自分はこんな感想を持ちました。 「 "ブラウザベースの .NET による Web アプリ" ってなんのこっちゃ? まだ実験段階的なこと書
GitHubの活動実績が雇用や就職でまったく役に立たない理由とは？
GitホスティングサービスのGitHubでは、さまざまな開発者がオープンソースソフトを公開しており、中には驚くべき高度なプログラムも見られます。プログラマーとしての腕を披露する場としての意味合いもあるGitHubですが、技術者を雇い入れようとする人や、雇ってもらおうという技術者にとって、GitHubでの活動実績であるGitHubプロファイルは、ほとんど意味のないものだという意見があります。 Why GitHub Won't Help You With Hiring https://www.benfrederickson.com/github-wont-help-with-hiring/ カナダ・バンクーバー在住のソフトウェア開発者のベン・フレデリクソン氏は、GitHubの活動実績が技術者としての就職に有利に働くと考えるべきではないと述べています。フレデリクソン氏は、同種の主張をする「The
開発会社におけるエンジニアスキル向上施策の過去と今｜TechRacho by BPS株式会社
morimorihoge@Webチーム部長です。ご無沙汰しています。ゴ魔乙はギルド戦が実装されてから拘束時間が多くなり、そろそろ見切りを付けようかとも思い始めた今日この頃です。とりあえずポケモンGOは始めました。 しばらくTechRachoに投稿できていなかったわけですが、別に遊んでいたわけではなく、むしろ開発会社としての本業の方で一杯一杯でなかなか記事を書く気合を充填できていませんでした。 今回は、最近社内で（というか主に僕のいるWebチームで）取り組んでいる社内エンジニアのスキルアップへの取り組みについて、これまでの経過と近況を書こうと思います。長いです。 ※今年に入ってから弊社は事業拡大を目指して採用活動を強化しており、現在進行形でメンバの増強を行っています。新しい人が入ってくる中で古くからの人もいるという当たり前のことではありますが、過去にこういう取り組みをしていたんだよという記録
Google Spreadsheet を簡易 Webサーバーとして動かして、手軽にWebHookを受け取る方法 - Qiita
外部のサービスからの通知を WebHookで受け取ってちょっとした処理をしたいことってたまにありませんか？ たとえば、アプリのクラッシュログを解析するFabricの Crashlytics には、新しいクラッシュが発生したり特定の閾値を超えると WebHookで通知してくれる、つまり特定の URL にPOSTを発行してくれる機能があります。 これを上手く使うと、下の図のように「新しいクラッシュが発生したら Backlogなどのチケット管理サービスに自動登録」といったことができそうです。 もちろんCrashlyticsから BacklogのAPIは直接叩けないので、このように WebHookを使ってこちらのサーバを叩いてもらい、そのサーバがあらためて Backlogの APIを使ってチケットを登録する、というよう感じになります。 以下は実際のClashlyticsの管理画面です。WebHoo
コメントを書かない理由 | おごちゃんの雑文
コードにコメントを書かない事を責められた時の言い訳 私はコードにコメントを書かない。それは面倒だとか、ここに書いてある事情があるとかではなくて、「信念」として書かない。書くべきではないと思っているからだ。コメントを書いたら負けだとさえ思っている。これはもう20年来そうだ。 ちょっとしたメモのようなコメントは、つい書きたくなる。私は「自分のコードは他人も見る」「過去の自分は他人」と思っているので、その時の助けになるようなコメントはむしろ入れたい欲求にかられる。コメントで意思伝達しておけば楽だと思う。が、「コメントを書いたら負け」だと思っているから書かない。 例外的に書くのは、 ファイルの冒頭に書くGNUなヘッダ ヘッダファイルに書く構造体の宣言 コメントアウト くらいで(これらはむしろ積極的に書く)、その書かないっぷりは、gotoよりも少ないくらいだ。 なんでそこまでコメントを嫌うかと言えば
ラムダ計算基礎文法最速マスター - 貳佰伍拾陸夜日記
ラムダ計算は, 多くのプログラミング言語, とくに関数型言語の原形になっています. ラムダ計算について理解しておくことは, 多くのプログラミング言語の習得に役立つでしょう. ラムダ計算はチューリング完全で, 計算能力としてはふつうのプログラミング言語と同じです. ラムダ計算で計算を書く訓練をしておくことは, 任意の計算を関数のみを使って(他の制御構文を用いずに)書くときに役立ちます. ふつうに書いたら煩雑な処理を, 関数型言語のやり方で書くとすっきりすることが多々あり, コードを自由自在に書くためには必須の考え方と言えるでしょう. 項 ラムダ計算の式を項(term)と言います. 項は変数, 抽象, 適用のいずれかです. 変数 変数(variable)はふつう1文字で書きます. 変数には関数内の束縛変数(bound variable)か自由変数(free variable)かという区別があり
プログラムにコメント書かない文化もあるよって話｜NZ MoyaSystem
以下の記事を読んで。 530000micro.hatenablog.com 僕が勤めている会社では、原則、プログラムにコメントを書かないのがルールです。 人生で初めてプログラムに触れてからこのかた、プログラムには必ずコメントを書けと指導されて来ましたし、自分自身も、後輩たちにちゃんとコメント書けよと言い聞かせてきました。そんなわけで、最初に全然コメントのないソースコードの山を見たときは、正直「ゲッ、なんじゃこりゃ……」と面食らったのは確かです。 ところが、「なぜうちのプログラムにはコメントがないのか？」と同僚に尋ねてみると、実に納得の行く回答が返ってきたのでした。 なぜコメントが必要なプログラムを書くのか？ 同僚いわく、「コメントが無くても読めるようなプログラムを書け」という思想が根底にあるのだそう。 適切に関数や変数が命名され、スコープがきちんと管理され、ロジックの流れが整理されているコ
プログラムソースにコメントを書くか？：プログラマー社長のブログ：オルタナティブ・ブログ
たまにはプログラミングネタでも。 先日ProDHCPのお問い合わせいただいたお客さんとのミーティングの際に、ProDHCPのソースライセンスの購入も検討しているというお話しになり、そのときに、「開発言語は何ですか？」「ソースのボリュームはどのくらいですか？」という感じにご質問をいただき、最後に「ソースにコメントはどのくらい書いてありますか？」との質問をいただきました。 私の返答は、 「ソースにコメントはほとんど書きません！」 です。お客さんは、ソースのボリュームに対してコメントのボリュームがどのくらいあるのかを知りたいという意味合いもあったようですが、ソースにコメントが必要かどうかという議論は、私が若い頃からずーっと盛り上がるテーマの1つです。 私の考えは、 コメントを見ないと理解できないようなソースでは駄目。シンプルでわかりやすいソースこそ、バグが少なく性能も高い。 コメントは度重なる仕
「型」のお気持ち 〜 「型なし」と「動的型」って同じ？違う？ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「『型なし』と『動的型』って同じ？違う？」「ピピーッ！JavaScriptやRubyを『型なし言語』と呼ぶのは間違いです！」 ツイッターを見ていると、このように「型」という言葉の用法に混乱がみられるので、私見で整理してみたいと思います。 まず、「型」という言葉の用法には、大きく分けて2つあります： 変数や関数についての静的にわかる性質 静的型言語では「型」と言ったら主にこちらを指します。 値の種類を区別するための実行時のタグ付け（型タグ） 「動的型言語」と言った場合の「型」はこちらです。 静的型言語でも「実行時型情報」という名
コメントの9割は無駄！～アンチプラクティスから学ぶ洗練されたコメントの書き方～ #code #コード｜CodeIQ MAGAZINE
コメントは基礎的で一般的なものでありながら、「どのようなことをコメントに残すか」は経験のあるプログラマにとっても難しいもの。 この記事では、アンチパターンコメントを見ながら、どのようなコメントを残すべきかについて説明します。 by 馬場美由紀 （CodeIQ中の人） コードは機械のために、コメントは人間のために? プログラミング言語を学ぶとき、コメントは最初に習う項目のひとつです。そして、プログラムであればコメントを含んでいることが普通です。ある研究によれば、ソースコードの平均19%がコメントだそうです。 コードを書くとき、私たちは機械とコミュニケーションを取ることを意識しています。機械はコードを認識してコンパイルしたり実行してくれます。解釈できなければ教えてくれます。プログラマは、コンパイラのためにデータ型を明示するコードを書いたりもします。 一方、コメントは人間とコミュニケーションする
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マニアが潰したテスト駆動開発〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （５）
SOLIDの原則ってどんなふうに使うの？
ずっと受けたかったソフトウェアエンジニアリングの新人研修 開発現場編