前言： 就像上次有提到的，這個meetup主要是由IBM的 BlueMix團隊的人主辦的． 但是相當有趣的是主要是來研究各種不同的PaaS的部分．這是第二次參加主講的部分是AWS與 Docker 心得： 第一部分：   AWS 的部分很有趣，也開了AWS的帳號．發現建立一個Beantalk 相當的方便． 這次在Coscup裡面也有聽到其實AWS裡面有相當大的一個DevOps的一系列工具．不僅僅能當PaaS連，IaaS都有類似的功能． CLI的操作起來也是學習Heroku，這部分久不需要詳談．這次參加也發現 AWS Beanstalk 其實有支援docker了． 第二部分： 這個部分的講解相當的Cool，主要是利用 Dokku 來架設一個lightweight 的 Heroku在 DigitalOcean上面． 在這裡面docker是為了讓dokku能夠跑出類似heroku的不同dyno 的功能， 類似這樣應用其實挺有趣的，也不斷的思考有沒有什麼特別的應用可以來用． AWS (Amazon Web Service)  Beanstalk  (slide) 主講人：  Moogoo QLL Engineer using Cornora SDK Amazone Web Service architecture: http://www.trisys.co.uk/support/documents/AWS/Web%20Application%20Hosting.jpg 優點： 快速部署，方便管理 整合AWS服務 EC2 （運算） S3 （File storage) SNS (message queuing) Cloud Watch  Elastic Load balance Auto Scaling 比較一下: Elastic Beanstalk Application container OpsWorks 利用 shelf 的部署檔，可以把各個主機部署的狀況寫成部署檔來掌控 Similar with puppet? http://puppetlabs.com/ Compare with Puppet and OpsWorkhttp://www.scriptrock.com/articles/opsworks-vs-puppet Could Formation Template-driven provisioning Deployment working flow: Create Application -> Upload version -> launch Environment -> manage Environment Deployment command line toolkit (refer here) Demo (Python -> AWS EB with Flask) Local run Implement Application.py (for Flask) Add Requirement.txt (similar with heroku virtualenv -> pip freeze ) init Git Tools : git aws.push eb start Server type  LoadBalance RDS (Relation Database ) eb stop (to kill application) 注意： 如果EB 移除的時候，該DB 也會一起被移除．...

前言： 這些學習主要都是針對Mooc 上面的課程(Programming Cloud Service)所學到的一些部分． 雖然說同時在學習Golang跟Java 是有一些混亂的，能夠學習一下關於Java上面架設REST Server的方法有是挺有趣的． 第一個作業大綱與心得：  這個課程的第一份作業其實相當的有趣，就是實作一個REST 的server可以查詢video info 還有就是能夠上傳video． 雖然相當有趣，但是其實讓我相當的苦惱．就是整個Controller的parameter到底該怎麼設計才能讓Retrofit  能夠正確的讀取與呼叫到． 其實如果Java或是Spring有點熟悉的人應該可以快速地完成第一次的作業．我卻也繳了不少時間當學費來好好學習整個架構與溝通的方法． Spring Boot: 簡介： Spring Boot 可以快速的幫助你建立一個Java Based 的俱有REST 的Web Application． 使用上的筆記: 比較需要管理的只有兩個部分，一個是Application.java 另外一個是Controller.java ．其中檔名可以改，但是需要有annotation 來表明清楚哪個是application 哪個是 controller． 其中關於Controller裡面，重點是需要有 annotation 註名是 controller @Controller 相較於Java Serverlet 對於 Web Request 的處理上，Spring Boot 相對的簡單多了．不需要繼承 HttpServlet 然後去 overwrite doGet 跟 doPost，只需要在前端去註解出這個function 要對應到哪個http request． @RequestMapping(value=“videos”, method=RequestMethod.POST) 這個就是代表著 ，只要從http XXXXvideos的 POST request 都會轉到這個地方． 對於去處理Http Request的部分，最麻煩了不外乎是處理 輸入與輸出的參數，而Spring Boot 可以很漂亮的做出這件事情． @RequestBody/@ResponseBody 這個會自動地把參數轉成你所要求的，不論是把Boolean轉成@ResponseBody(JSON的形態） 或是把@RequestBody轉成你所要求的變數形態． 更改運作的port (change connection port) 官方提出兩個方法，不過我是第二個才成功． 新增 application.properties 在 src/main/resources/  並且加上 server.port = 9000 在 Eclipse 的properties -> Run/Debug Settings -> Application -> Environment -> Add [SERVER_PORT] = 9000 同時需要debug - Server 與 Client (test) 先跑 Server - debug as Java Application (設定好break point) 再接者跑test - debug as JUnit test 在同時做 server  與 client debug 的時候，常常會有一個動作卡在 client 之後 server就沒回應．或是專心的看server的code，client 就停住了． 我會繼續研究看看． 對於 /path/{id} 這一類型的RequestMapping 需要使用以下，不然會找不到: @RequestMapping(value=“/departments/{departmentId}”)</br>public String findDepatmentAlternative(@PathVariable(“departmentId”)String someDepartmentId)</br>{… } 對於multipart 的敘述，一開始不是很了解會以為是POST的必須的API．回去看了關於Retrofit 的敘述才知道Multipart只針對檔案的上傳 他在controller裡面對應的API是 @RequestParam(”data”) MultipartFile uploadFiles… 其實在實作controller的時候，是不需要參考Retrofit 的API，那個API只是幫助你的test client 知道該怎麼跟server溝通．...

Taiwan PaaS Meetup http://www.meetup.com/%E5%8F%B0%E7%81%A3-PaaS-%E9%9B%B2%E7%AB%AF%E6%8A%80%E8%A1%93%E4%BA%A4%E6%B5%81%E6%9C%83/about/ Meetup PaaS HackPad: https://paas-tw.hackpad.com/Getting-Started-with-Pivotal-Web-Services-PadMnuFp1vd 總結： 相較於Pivotal (Cloud Foundry) ，Heroku可能真的比較廉價． 收費方式都不是算流量： Pivotal : 記憶體 Heroku: 依照計算能力 Dyno 自動Scale Pivotal似乎沒有自動調節scale 的能力． Heroki似乎沒有看到 與git的搭配: Pivotal並沒有 heroku 不僅僅原生就支援git，也可以直接跟github互動． 心得： 這次參加的人數不算多，不過倒是很多高手．有看到ihower 還有似乎是他同公司的mose．可見PaaS再用的人真的都不是DevOP的人而是developer． 文創中心算是不錯的場地，交通也算方便．場地費似乎也不貴．其他人要辦活動挺推的． 看起來Pivotal跟 Heroku沒有太多差異，但是 Heroku有免費的方式， Pivotal卻沒有，可能在初期是可以先用 Heroku 正式上線後再考慮要不要挑到 Pivotal． 有很多的討論都可以看出來PaaS跟docker有更多的交錯，只是接下來接近會走向dokku 還是???     Pivotal: 網站： http://www.pivotal.io 計價方式與免費部分: 計價方式是根據所使用的總記憶體部分． 免費部分: 2GB RAM，10個market place service(十台service) 基本app 單位 warden 有可能換成 docker container  http://www.activestate.com/blog/2014/04/docker-and-cloud-foundry 部署流程(Deploy workflow): 必須要準備一份 manifest.yml，裡面包括： Disk_quota host, name, path Memory size. command (app entry point) cf push APP_NAME 更多參考 http://docs.run.pivotal.io/devguide/deploy-apps/deploy-app.html 可能遇到問題： domain name conflict  不像是Heroku有自動配置名字，所以很容易跟其他人名稱衝突（在push的時候會發生） 需要修改manifest 去解決這個問題． 使用的語言沒有支援的buildpack (Ex: Scala) 可以使用heroku 的buildpack   cf push -b heroku_build_pack  Q&A: Q: 備份的機制? 比較沒有相關的備份機制．甚至跟git 的互動都沒有． Q: 流量的計算？ 由於是靠記憶體來收費，所以任何app在deploy之後就馬上會開始收費（就算沒有人用) 參考: Warden 換成 Docker http://www.activestate.com/blog/2014/04/docker-and-cloud-foundry Go-buildpack  https://github.com/cloudfoundry/go-buildpack 總共支援: PHP/GO/RUBY/PYTHON/JAVA/node.JS  http://docs.run.pivotal.io/buildpacks/ Cloud Foundry https://github.com/cloudfoundry Pivotal - Rewrite Cloud Foundry from Ruby to Go https://github.com/cloudfoundry/cli/releases Deploy application on Cloud Foundry http://pivotallabs.com/deploying-jruby-rails-application-cloud-foundry/ 深入 Cloud Foundry http://qing.blog.sina.com.cn/2294942122/88ca09aa330004r8.html?sudaref=www.google.com.tw Cloud Foundry 分佈式架構 http://blog.lamper.cn/cloud-foundry%E5%88%86%E5%B8%83%E5%BC%8F%E6%9E%B6%E6%9E%84%E6%A6%82%E8%BF%B0/   Heroku:   /her-OH-koo/  架構： Slug Compiler -> Slug Slug -> dyno (based on scale) Dyno 特性: isolated...

前言： 自學Golang也到了現在，除了繼續深究Golang在許多層面的應用之外．也必須學習一些新的資料庫． 想了一下，就決定拿經常在研討會裡面看到的NOSQL (並不是 NO - SQL 而是 Not-Only SQL )的資料庫 MongoDB來練習一下． MongoDB比起一般的RDBMS而言，應該算是比較容易了解的．而且對於從手機程式設計開始學習的人可能會更容易上手． 因為 MongoDB本身不斷圍繞著一個資料結構，就是 JSON． MongoDB: 關於: 本身概念相當的簡單，主要分為Database(資料庫)， Collection (中文該怎麼翻比較順呢？) 還有就是最基本的資料原件 Document (文件)． 這樣如果還不是很容易了解，換這樣來換吧:   DB一樣就是原先RDBMS裡面的資料庫 Collection 可以當成一個個的Table Document 可以當成一個個的Record 這樣並不是最好的對比，不過這是一個概念上可以讓人一開始馬上進入的方法． 安裝或使用： 如果要自己架設MongoDB(Mac OS)可以參考一下這裡，或者是去 MongoDB HQ上面申請一個免費的MongoDB (我目前是申請一個免費的資料庫來測試） 使用上需要注意的特點: 由於你的資料欄位最基本是JSON，所以每個Collection 裡面並沒有固定的欄位格式．可以前兩個documents 是有五個欄位，後面卻不是． 關於查詢 equal 比較簡單，就是一般JSON語法  { price: 40 } 查詢價錢40元的 greater than (大於) 或是 Less than (ls）的時候需要使用   { price: { $gt : 40} } (查詢價錢 大於 45)  (要查小於就是  $lt ） Golang上面大家推薦的MongoDB Driver — mgo 其實安裝跟使用相當的簡單，裡面也提供很多好用的方法．不過我在學習的途中有遇到一些問題希望可以幫助大家． Document 的type struct 裡面的資料名稱，不可以全部小寫(lowercase)不然會出現insert到collection 裡面變成空白（empty document except ObjectID)． 我本身有在追他的source code但是還看不出是在哪裡有問題． (承上)雖然變數名稱必須有大寫(uppercase)但是到了MongoDB裡面又得用全部小寫(lowercase)．在一般的資料庫操作中，這是可以理解的． 關於Query Criteria 的參數 要下greater than 必須用 $gt  範例：  bson.M{"price": bson.M{"$gt": 40}} 找出價錢大於40 基本的查詢與操作都會了之後，接下來要弄到Heroku上面去跟server搭配了． 範例可以到這裡去找 Github ….. 參考： http://blog.joshsoftware.com/2014/02/28/a-simple-go-web-app-on-heroku-with-mongodb-on-mongohq/ http://www.codedata.com.tw/database/mongodb-tutorial-1-setting-up-cloud-env/ http://www.codedata.com.tw/database/mongodb-tutorial-2-query-language/ http://docs.mongohq.com/getting-started/mongohq.html https://gist.github.com/border/3489566

最近有一些值得記錄的部分，隨手寫一下: SDL_CloseAudio 會發生一些問題 (deadlock)，如果Server 已經斷線了． 發生狀況： 當RTSP Server斷線或是網路中斷的時候，嘗試著去Close SDL 會產生deadlock 在 SDL_CloseAudio 如果封包持續進來的狀況下，不會有任何問題． 主要原因： 根據SDL source code， RunAudio 裡面會去 OpenMutex讀取資料．這個狀況下，如果Server斷線（或是網路斷線) 會造成一直在等封包的結束．必須等到每個封包做完後會SDL_Delay特定時間，這時候就可以順利關閉設備． 解決方式： 為了解決這種deadlock的狀況，要試著去關閉設備的時候，先送一個空的封包進去．讓SDL跑到等待下一個封包的進入才能順利關閉． 參考: http://stackoverflow.com/questions/24926019/try-to-close-sdl-closeaudio-has-deadlock-when-rtsp-server-is-down/24926020#24926020 SDL_DestroyWindow 有threading 的問題，SDL_CreateWindow 必須要跟SDL_DestroyWindow 在同一個thread 發生狀況： 使用SDL_DestroyWindow 會發生no response(hang)，如果SDL_DestroyWindow與SDL_DestroyWindow在不同的thread． 解決方式： 本來都以為是因為必須在UI thread，但是由於我自己架設的環境RTSP 是在另外一個thread去執行，以致於不會卡住所有UI response． 後來發現用另外一個thread來處理RTSP，也是可以讓SDL來render畫面與聲音的輸出．但是在SDL_DestroyWindow的時候就會卡住． 後來調整後，就發現可以正常的SDL_DestroyWindow． 參考： http://forums.libsdl.org/viewtopic.php?p=40752&sid=245abd9df9be7b7ecf6dc59d7388dc66  這個討論串主要是談到iOS不過似乎Windows也是一樣的． SDL_DestroyWindow mongo kahana.mongohq.com:10042/MongoTest1 -u -p

前言： 在07/23更新了粉絲相簿到v1.2版本，主要是修復不論是視覺界面的問題，還有操作上的一些問題． 主要修復: 美化icon解析度，修復視覺問題 修復使用者端資料庫會產生錯誤讀取的問題 修復許多操作上的問題 雜言： 這次更新的上架速度比我想像中的快了很多，大概一個禮拜就可以正式上架．果然更新跟第一次上架有天壤之別． 此外～自己來寫app真的很難做完全的測試．每次都是上架後，朋友才會來跟我講哪裡有問題，哪裡有錯誤． 這樣一直更新都讓自己覺得不好意思  XD   最近有人問我一些問題，在這裡寫一下幾個FAQ Q： 這個APP寫了多久？ Ａ：這個ＡＰＰ總共前前後後寫了一年多．從我買Macbook Air到現在 ．前後貫穿了從我完全不會寫iOS到現在（也沒多懂@_@） Q：這個App有用到哪些技術呢？ 這個問題比較複雜一點，裡面主要有用到幾個ＳＤＫ: Facebook SDK 主要就是讀取粉絲相簿與資料，其中也包括了 Single-Sign-On Parse SDK 就是網路伺服器與資料庫管理的部分使用Parse，一個簡單使用並且在某些流量下是免費的PaaS． 可以讓我存取一些資料庫，還可以發送push notification． FGallery 主要負責的就是各位看到的相簿瀏覽的部分，我知道裡面有許多的問題．比如說：不能批次讀取，滑動會上下，不能暫存等等． 這些部分的加強就會擺在之後，當然也是我更熟悉後． Q：App的資料哪裡來？ A：主要都是網友分享的，所以也希望又更多網友能夠分享你們喜歡的粉絲頁面給大家，讓這個更好用．