หมวดหมู่: การพัฒนาซอฟท์แวร์

Categories
Android iOS Mobile

สรุปการใช้งาน Cordova (PhoneGap)

Cordova จะทำงานร่วมกับ SDK ของ Mobile แต่ละ Platform ดังนั้นก่อนติดตั้ง Cordova ต้องติดตั้ง SDK ของแต่ละ Platform ก่อน

 

การติดตั้งบน Windows

  1. Java JDK  เวอร์ชั่น 6 ขึ้นไป ทดลองคำสั่ง java -version
  2. Android Studio http://developer.android.com/sdk
  3. ติดตั้ง Node.Js ดาวน์โหลดได้จาก http://nodejs.org
    • เมื่อติดตั้งเสร็จแล้วทดลองด้วยคำสั่ง npm -v ถ้าใช้ไม่ได้ลองรีบูทเครื่อง
  4. ติดตั้ง Git ดาวน์โหลดจาก http://git-scm.com เสร็จแล้วกำหนด PATH ไปที่ไดเรกทอรี่ bin ของ Git ด้วย แล้วทดลองคำสั่ง git –version
  5. ติดตั้ง Apache Ant ดาวน์โหลด zip ได้ที่ http://ant.apache.org/
    • แล้วคลาย zip ไปที่โฟลเดอร์ใดก็ได้
    • เพิ่ม ANT_HOME ให้ชี้ไปที่พาทของ Ant เช่น C:\ant\Apache-ant-x.x.x
    • เพิ่มโฟลเดอร์ bin ของ Ant ไปที่ PATH
    • ทดลองคำสั่ง ant -version
  6. ติดตั้ง Cordova โดยพิมพ์คำสั่ง npm install -g cordova
    • แล้วลองคำสั่ง cordova -v

 

ติดตั้งบน Mac

  1. Java JDK  เวอร์ชั่น 6 ขึ้นไป ทดลองคำสั่ง java -version
  2. Android Studio http://developer.android.com/sdk
  3. ติดตั้ง Node.Js ดาวน์โหลดได้จาก http://nodejs.org
    • เมื่อติดตั้งเสร็จแล้วทดลองด้วยคำสั่ง npm -v
  4. ติดตั้ง Git ดาวน์โหลดจาก http://git-scm.com แล้วทดลองคำสั่ง git –version
  5. ติดตั้ง Apache Ant
    • ใช้คำสั่ง brew install ant ถ้าหากไม่มีคำสั่ง brew ให้ติดตั้ง Homebrew ด้วยคำสั่ง
    • ruby -e “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)”ทดลองคำสั่ง ant -version
  6. ติดตั้ง Cordova โดยพิมพ์คำสั่ง npm install -g cordova
    • แล้วลองคำสั่ง cordova -v
  7. ติดตั้ง Xcode
  8. ติดตั้ง ios-sim ด้วยคำสั่ง sudo npm install ios-sim -g
  9. ติดตั้ง ios-deploy ด้วยคำสั่ง sudo npm install -g ios-deploy
    • ทดลองรัน iOS Simulator โดยเรียก
      • ios-sim –version
      • ios-sim start
      • ios-sim start –retina –tall

 

การสร้าง App เบื้องต้น

  1. สร้างโปรเจคใหม่
    cordova -d create ชื่อโฟลเดอร์แอพ ชื่อแพคเกจ ชื่อแอพ
  2. เพิ่ม platform
    cordova platform add ios
    cordova platform add android
    หรือ
    cordova platform add ios android

    • ถ้าต้องการดู platform ที่เพิ่มเข้ามาแล้ว
      cordova platform ls
    • ถ้าต้องการลบ platform
      cordova platform remove android
  3. การสั่ง Build
    cordova build
    หรือ
    cordova build android
    cordova build ios
  4. การสั่ง Run บน Simulator
    cordova emulate android
    หรือ
    cordova emulate ios
  5. การสั่ง Run บนมือถือจริง (ถ้า Windows ต้องติดตั้ง driver ก่อน, แต่ Mac OS X สามารถเสียบอุปกรณ์ได้เลย)
    cordova run android
    หรือ
    cordova run ios
Categories
Android Mobile

Android App Development for Beginners Playlist

Categories
การพัฒนาซอฟท์แวร์

หลักการเขียนโปรแกรม 50 ข้อ

บางข้อเก่าไปแล้ว แต่หลายข้อยังใช้ได้

1.โปรแกรมแบบพอเพียง(ทำอะไรให้เล็กที่สุดเท่าที่เป็น ไปได้)

2.ทำสิ่งธรรมดาให้ง่าย ทำสิ่งยากให้เป็นไปได้

3.จงโปรแกรมโดยนึกว่าจะมีคนมาทำต่ออย่างแน่นอน

4.ระเบียบ กฏข้อบังคับ เชื่อมั่นไม่ได้แล้ว ถ้ามีเพียงหนึ่งโมดูลไม่ปฏิบัติตาม

5.ตัดสินใจให้ดีระหว่างความชัดเจน(clearance) กับ การขยายได้(extensibility)

6.อย่าเชื่อมั่น output จากโมดูลอื่น ถึงแม้เราจะเป็นคนเขียนเอง

7.ถ้าคนเขียนยังเข้าใจได้ยาก แล้วคนอ่านจะเข้าใจได้ยากกว่าแค่ไหน

8.ค้นหาข้อมูลสามวันแล้วทำหนึ่งวัน หรือจะทำสามวันแล้วแก้บั๊กตลอดไป

9.จงสร้างเครื่องมือ ก่อนทำงาน

10.อย่าโทษโมดูลอื่นก่อน โดยเฉพาะถ้าโมดูลอื่นเป็น OS และ Compiler

11.พยายามทำตามกฏ แต่ถ้ามีข้อยกเว้น ต้องมีอย่างหลีกเลี่ยงไม่ได้ แล้วประกาศและตะโกนให้ดังที่สุด

12.High cohesion Loose coupling. (ยึดเกาะให้สูงสุดในโมดูล และ เกาะเกี่ยวกับโมดูลอื่นให้น้อยที่สุด)

13.ให้สิ่งที่เกี่ยวข้องกันยิ่งมากอยู่ไกล้กันมากที่ สุด

14.อย่าเชื่อโดยไม่พิสูจน์

15.อย่าลองทำแล้วคอมไพล์ดู ถ้าเราไม่ได้คาดหวังผลลัพธ์อะไรไว้ (อย่างเช่นปัญหา index off by one)

16.จงกระจายความรู้เพราะนั่นคือการทำ Unit Test ระดับล่างสุด(ระดับความคิด)

17.อย่าเอาทุกอย่างใส่ใน UI เพราะ UI คือส่วนที่ Unit Test ได้ยาก

18.ทั้งโปรเจ็คต์ควรไปในทางเดียวกันมากที่สุด( Consistency )

19.ถ้ามีสิ่งที่ดีอยู่แล้วจงใช้มัน อย่าเขียนเอง ถ้าจำเป็นต้องเขียนเอง ให้ศึกษาจากข้อผิดพลาดในอดีตก่อน

20.อย่ามั่นใจเอาโค้ดไปใช้จนกว่าจะ test อย่างเพียงพอ

21.เอาโค้ดที่ test ไว้ที่เดียวกันกับโค้ดที่ถูก test เสมอ

22.ทุกครั้งที่แก้ไขโค้ดให้ run unit test ทุกครั้ง

23.จงใช้ Unit Test แต่อย่าเชื่อมั่นทุกอย่างใน Unit Test เพราะ Unit Test ก็ผิดได้

24.ถ้าต้องทำอะไรที่ซ้ำกันมากกว่าหนึ่งครั้ง ก็เพียงพอแล้วที่จะแยกโค้ดส่วนนั้นออก

25.ทำให้ใช้งานได้ก่อน แล้วค่อย optimize และถ้าไม่จำเป็น อย่าoptimize

26.ยิ่งประสิทธิภาพเพิ่ม ความเข้าใจง่ายจะลดลง

27.ใช้ Design Pattern ที่เป็นที่รู้จักจะได้คุยกับใครได้รู้เรื่อง

28.อย่าเก็บไว้ทำทีหลัง ถ้ายังไงก็ต้องทำ

29.MutiThreading ไม่ใช่แค่การเพิ่มประสิทธิภาพ แต่มันมาพร้อมกับ Concerency, Deadlock, IsolationLevel, Hard to debug, Undeterministic Errors.

30.จงทำอย่างโจ่งแจ้ง

31.อย่าเพิ่ม technology โดยไม่จำเป็น เพราะนั่นทำให้โปรแกรมเมอร์ต้องวุ่นวายมากขึ้น

32.จงทำโปรเจ็คต์ โดยคิดว่าความเปลี่ยนแปลงเกิดขึ้นได้เสมอ

33.อย่าย่อชื่อตัวแปรถ้าไม่จำเป็น เดี๋ยวนี้ IDE มันช่วยขึ้นเยอะแล้วไม่ต้องพิมพ์เองแค่ dot มันก็ขึ้นมาให้เลือก

34.อย่าใช้ i, j , k , result, index , name, param เป็นชื่อตัวแปร

35.ทำโค้ดที่ต้องสื่อสารผ่านเครือข่ายให้คุยกันน้อยท ี่สุด

36.แบ่งแยกดีดี ระหว่าง Exception message ในแต่ละเลเยอร์ ว่าต้องการบอกผู้ใช้ หรือ บอกโปรแกรมเมอร์

37.ที่ระดับ UI ต้องมี catch all exception เสมอเพื่อกรอง Exception ที่ลืมดักจับ

38.ระวัง คอลัมภ์ allow null ใน database ดีดี ค่า มัน convert ไม่ได้

39. อย่าลืมว่า Database เป็น global variable ประเภทหนึ่ง แต่ละโปรแกรมที่ติดต่อเปรียบเหมือน MultiThreading ดังนั้นกฏของ Multithreading ต้องกระทำเมื่อทำงานกับ Database

40.ระวังอย่าให้ logic if then else ซ้อนกันมากมาก เพราะสมองคนไม่ใช่ CPU จินตนาการไม่ออกหรอกว่ามันอยู่ตรงไหนเวลา Debug (ถ้ามากกว่าสามชั้นก็ลองคิดใหม่ดูว่าเขียนแบบอื่นได้ มั้ย)

41.ระวังอย่าให้ลูปซ้อนกันมากมาก ไม่ใช่แค่เรื่องความเร็วอย่างเดียว เวลา Debug เราคิดตามมันไม่ได้ (ถ้าเกินสามชั้นก็ไม่ไหวแล้ว)

42. อย่าใช้ Magic Number ใน Code เช่น if( controlingValue == 4 ) เปลี่ยนไปใช้ Enum ดีกว่า เป็น if( controlingValue == ControllingState.NORMAL ) เข้าใจง่ายกว่ามั้ย

43.ถ้าจะเปรียบเทียบ string Trim ซ้ายขวาก่อนเสมอ

44.คิดหลายๆ ครั้งก่อนใช้ Trigger

45.โปรแกรมเมอร์คือห่วงโซ่สุดท้ายของมลพิษทางความซับ ซ้อน ดังนั้นหา project leader ดีดีแล้วกัน

46. มนุษย์ฉลาดกว่าคอมพิวเตอร์ การเขียนโปรแกรมก็คือการสอนให้คอมพิวเตอร์ฉลาดได้เหม ือนเรา (มนุษย์ฉลาดกว่าคอมพิวเตอร์จริงๆนะ) Reply With Quote

47. จงควบคุมคอม มิใช่ให้คอมควบคุมเรา เราต้องสั่งให้คอมทำงาน ไม่ใช่ให้เราทำงานตามคอมสั่ง

48. อย่าปล่อยให้ข้อจำกัดของคอม มาจำกัดความคิดของเรา [คอมไม่ดีเปลี่ยนเครื่องเลย 55+]

49. ยอมรับความคิดของผู้อื่น แต่อย่าออกจากกรอบของตนเอง

50. หมั่น Save โปรแกรมไว้อย่าสม่ำเสมอ ก่อนที่จะไม่มีโอกาส Save [จะให้ดี Save เป็นแต่ละ Version เลย] [ ใช้ Version Control System สิ ]

ที่มา: https://www.blognone.com/node/2286

Categories
Web site

Resources, Tools และ Plugins สำหรับคนทำเว็บ

CSS tools and resources
img
CSShake
Some CSS classes to move your DOM! Impressive effects with minimum of effort.
img
Magic animations
CSS3 Animations with special effects. Just include the CSS style: magic.css or include the mynified version: magic.min.css
img
Hover.css
A collection of CSS3 powered hover effects to be applied to links, buttons, logos, SVG, featured images and so on.
img
typebase.css
Typebase.css is a minimal, customizable typography stylesheet.
img
Materialize
A modern responsive front-end framework based on Material Design
img
Material UI
A CSS Framework and a Set of React Components that Implement Google’s Material Design
img
CSS Shrink
A CSS minifier built because CSS is on the critical path to rendering pages. It must be small! Or else!
img
Power To CSS
A well designed CSS framework, based on the principles of SMACSS and DRY.
img
Flexbox Grid
A grid system based on the flex display property. A neat grid system that you can start using today.
jQuery plugins
img
pagePiling.js
pagePiling plugin by Alvaro Trigo. Create a scrolling pile of sections.
img
fullPage.js
A simple and easy to use plugin to create fullscreen scrolling websites.
img
Animsition
A simple and easy jQuery plugin for CSS animated page transitions.
img
Flickerplate 
A cool jQuery plugin that lets you flick through content.This plugin is included within Webplate .
img
ScrollMe
A jQuery plugin for adding simple scrolling effects to web pages
img
Slidebars
Slidebars is a jQuery plugin for quickly and easily implementing app style off-canvas menus and sidebars into your website.
img
Magneticmediajs
A JavaScript and CSS solution to display media content in a stylish mobile-ready overlay fashion.
img
SVGMagic
A jQuery plugin that searches for SVG images on your website and creates PNG versions if the browser doesn’t support SVG.
img
Simple jQuery CSS3 slider
A simple slider that does what a simple slider has to do: slide slides!
CSS experiments
img
Pull Menu
Menu Interaction Concept. Just pull down and release to jump between pages.
img
Responsive Mail UI
t’s responsive until pretty darn small but i haven’t actually tested it on mobile devices.
img
Blurred Background CSS
Create blurred version of the background, and set the background property both of them to be cover sized and fixed.
img
Apple zoom out effect
Interesting effect that Apple used for a presentation of a product that designers managed to recreate.
img
CSS-only Weather App Concept
Dribbble rework of an original shot by Sergey Valiukh. Impressive at least.
img
Firewatch Parallax in CSS
The parallax header on the Firewatch website in CSS. It was originally meant as a daft experiment.
UI kits
img
Bootstrap 3 Vector UI Kit
This UI Kit contains all Twitter Bootstrap 3 UI controls in vector format,
img
Summer UI Kit 
Summer is a UI kit for designers and web developers that can be downloaded for free.
img
Sally Blocks
PSD blocks and elements for fast and simple creating of responsive websites.
img
Flat UI Kit
Nice and modern UI kit that will surely be of use for you. Download and use it.
img
Awesome UI Kit
Useful UI kit with few but interesting design elements, just good to make quick designs.
img
Free Flat UI Kit
Free .sketch UI kit for those who use Sketch App and want an UI kit in their toolkit.
Icons
img
Themify Icons
Themify Icons is a complete set of icons for use in web design and apps, consisting of 320+ icons.
img
Linea
A free outline iconset featuring 730+ Icons. Coded and designed by Dario Ferrando.
img
OPEN ICONIC
An open source icon set with 223 marks in SVG, webfont and raster formats
img
Touch Icon Set
A free collection of 340 touch icons designed at 24 x 24 pixels and scaled up for retina.
img
Icon Works
The icon pack TTF, EOT, WOFF, and SVG font files that are ready for you to use in your web projects.
img
150 outlined icons
A simple but useful icon set, completely free now and ever. Icons available in PSD, AI, SVG, Webfont format.
Categories
Android iOS Mobile Startup

เรียนรู้การสร้าง Mobile application จาก Facebook

มาลองดูแนวทางการพัฒนา Mobile App จากทีมงานของ facebook กันหน่อย

ที่มา http://www.somkiat.cc/how-facebook-make-mobile-app/

ในงาน @Scale Conference
ทีมพัฒนา Mobile application ของ Facebook ได้มาพูดเกี่ยวกับ
การพัฒนาระบบเพื่อให้สามารถทำงานได้บนมือถือและ network ต่างๆ ทั่วโลกได้

มาดูกันว่าทีมพัฒนาของ Facebook ทำการพัฒนา สร้าง product กันอย่างไร
เพื่อรองรับการใช้งานจากคนทั้งโลกกันอย่างไร

สิ่งที่ทางทีมพัฒนาชี้ประเด็นคือ

เรื่องความเร็ว network ของมือถือ
ซึ่งเป็นปัญหาแรกๆ ที่พบเจอ โดยสรุปได้ว่า

  • ในประเทศสหรัฐอเมริกา นั้นความเร็วของเครื่องข่าย 3G ใช้เวลาในการรับส่งข้อมูลต่อครั้ง 280 milisecond
  • ในประเทศอินเดีย นั้นความเร็วของเครื่องข่าย 3G ใช้เวลาในการรับส่งข้อมูลต่อครั้ง 500 milisecond
  • ในประเทศบราซิล นั้นความเร็วของเครื่องข่าย 3G ใช้เวลาในการรับส่งข้อมูลต่อครั้ง 800 milisecond

โดยทีมพัฒนาที่ทำการวิจัยสามารถสรุปกลุ่มผู้ใช้งาน facebook ไว้ง่ายๆ ว่า

Not everyone is on a fast
Not everyone has a large screen
Not everyone is on a fast network

ดังนั้น สิ่งที่ทางทีมพัฒนาจะเน้นเป็นพิเศษ คือ เรื่องปัญหาของ network

สิ่งที่ต้องจัดการประกอบไปด้วย 3 เรื่องคือ

  1. ขนาดของรูป ที่ต้องทำการ download ผ่าน network
  2. การตรวจสอบคุณภาพของ network ก่อนเลือกวิธีการทำงานให้เหมาะสม
  3. การแอบดึงข้อมูลบางส่วนมาก่อน

1. การลดขนาดของรูป

รูปแบบที่ใช้สำหรับรูปภาพคือ WebP
ซึ่งสร้างด้วยทีมของ Google ในปี 2010

จากข้อมูลของการใช้งาน Facebook for Android นั้นพบว่า 85% คือรูปภาพ
และ Facebook messenger นั้นพบว่า 67% คือรูปภาพ
ดังนั้น ถ้าสามารถลดขนาดของรูปภาพได้
ก็จะทำให้ application ทำงานได้เร็วขึ้น

ดังนั้นสิ่งที่ทีมพัฒนาต้องทำมีดังนี้

สิ่งแรกคือ การส่งข้อมูลที่เหมาะสมมาให้ผู้ใช้งาน
หมายความว่า จะทำการตรวจสอบก่อนว่าผู้ใช้งานนั้นเป็นอย่างไร
เช่นมีความเร็วของ network ความสามารถของมือถือ หรือ tablet และ ขนาดของหน้าจอ เป็นต้น
ทำให้ server สามารถเลือกข้อมูลที่เหมาะสมได้ เช่น ขนาดของภาพ
จะได้ไม่เปลือง bandwidth และ เปลืองเวลาในการรอของผู้ใช้งาน

แต่ในปัจจุบันเรื่องขนาดหน้าจอที่ใหญ่ และ ละเอียดขึ้น
ส่งผลให้ต้องส่งรูปภาพที่ละเอียด และ ขนาดใหญ่ขึ้น
ซึ่งวิธีการนี้อาจจะไม่ค่อยมีประสิทธิภาพเท่าไรนัก
แต่โดยรวมแล้วถือว่าคุ้มกับการลงมือทำ

สิ่งต่อมาคือ การเปลี่ยนรูปแบบของรูปภาพมาอยู่ในรูปแบบ WebP
ซึ่งสามารถลดขนาดของภาพ JPEG ลงไปได้ 7% เมื่อต้องการคุณภาพเท่ากัน
แต่ถ้าทำการเปลี่ยนแปลงค่าต่างๆ เช่นคุณภาพ สามารถลดขนาดภาพลงไปมากกว่า 30%
สามารถลดขนาดภาพลงไปมากกว่า 80% ของรูป PNG
เป็นการปรับปรุงที่ได้ผลดีมากมาย

สำหรับใน Android เวอร์ชั่นเก่าๆ ที่ไม่สนับสนุน WebP นั้น
ใช้วิธีการส่งข้อมูลเป็น WebP แต่ในการแสดงผลยังเป็น JPEG อยู่

2. การตรวจสอบคุณภาพของ Network

สิ่งหนึ่งที่ทางทีมพัฒนาได้เรียนรู้ก็คือ อย่าตัดสินเรื่องความเร็วของ Network ต่างๆ
ตาม technology เช่น 2G, 3G, LTE และ WIFI เป็นต้น
เพราะว่า แต่ละประเทศมันมีความเร็วที่แตกต่างกันมากพอสมควร

ดังนั้น สิ่งที่นำมาใช้ในการตัดสินใจก็คือ
การวัดจากความเร็วจากผู้ใช้งานที่เกิดขึ้นจริงๆ ณ ขณะนั้น

โดยจะวัดจากความเร็วของ network ที่ใช้งานตอนนั้น
ซึ่งทุกๆ response ที่ส่งกลับมาจาก server ของ Facebook
จะมี RTT (Round Trip Time) มาให้เสมอ เพื่อใช้ประมาณเวลาการรับส่งข้อมูล
และการตัดสินใจว่าจะส่งข้อมูลมาให้ด้วยคุณภาพสูงหรือต่ำเพียงใด
แบ่งออกเป็น 4 ระดับคือ

  1. Poor มีความเร็วน้อยกว่า 150kbps
  2. Moderate มีความเร็วระหว่าง 150-600kbps
  3. Good มีความเร็วระหว่า 600-2000kbps
  4. Excellent มีความเร็วมากกว่า 2000kbps ขึ้นไป

เมื่อรู้คุณภาพของ network แล้ว สิ่งที่จะต่อไปที่ต้องทำก็คือ

  • การเพิ่มหรือลดคุณภาพของข้อมูล
  • การส่งข้อมูลแบบขนานหรือไม่
  • การเปิดและปิด Auto play ของ VDO
  • การแอบดึงข้อมูลบางอย่างมาก่อน

ในการทดสอบนั้น ทีมพัฒนาได้สร้างระบบภายในที่เรียกว่า  Air Traffic Control ขึ้นมา
เพื่อจำลองรูปแบบต่างๆ ของ network
ทำให้เจอปัญหาที่ไม่คาดคิด บนระบบ network ที่ช้าได้อย่างรวดเร็ว
ซึ่งทำให้แก้ไขได้อย่างรวดเร็ว

3. การดึงข้อมูลบางส่วนมาไว้ก่อน (Prefetch content)

เนื่องจากปัญหาความเร็วของ Network ดังนั้นระบบอาจจะต้องทำการดึงข้อมูลบางอย่าง
ที่ยังไม่ถูกใช้งานมาเก็บไว้ก่อน ซึ่งข้อมูลเหล่านี้จำเป็นต่อการทำงาน

ยิ่งถ้า network ที่ช้าๆ แล้วจะพบว่า จะทำการดึงข้อมูลมาไม่ทัน
เช่นดึงข้อมูลมาไม่ได้ แล้ว ผู้ใช้งานจะพบเจอกับรูปภาพหน้าขาวขึ้นมา (ผมเจอประจำเลย)

โดยการดึงข้อมูลมาก่อนนั้น สามารถทำได้ตั้งแต่ตอนเปิด application ขึ้นมาใช้งาน
หรือทำในขณะที่กำลังใช้งานก็ได้

แต่สิ่งที่ต้องคำนึง คือ การดึงข้อมูลต้องไม่ไปทำให้ผู้ใช้งานสะดุด
หรือ block การใช้งานของผู้ใช้งานโดยเด็ดขาด
นั่นคือต้องแยกการทำงานระหว่าง foreground process และ background process ออกจากกัน
รวมทั้งไม่ดึงข้อมูลที่ผู้ใช้งานไม่จำเป็นมาด้วย

และสิ่งสำคัญสุดๆ ก็คือ
ต้องมีระบบ monitoring สำหรับดูว่าผู้ใช้งานแต่ละคนหรือแต่ละเครื่อง
ไม่ทำการดึงข้อมูลมาไว้ก่อนมากจนเกินไป ไม่เช่นนั้นจะเปลือง bandwidth การใช้งานมากๆ

ปิดท้าย

ทีมพัฒนานายังบอกด้วยว่า Facebook application for Android นั้นมีไฟล์ APK มากกว่า 20 ไฟล์
ซึ่งแยกตาม API Level, ขนาดของหน้าจอ และ สถาปัตยกรรมของ CPU อีกด้วย
มันไม่ใช่เรื่องที่ง่าย หรือ เล่นๆ เลยนะ

ดังนั้นลองนำแนวคิดเหล่านี้ ไปใช้เพื่อปรับปรุง Mobile application กันได้
น่าจะมีประโยชน์ไม่มากก็น้อยครับ

Reference VDO

Categories
Agile การพัฒนาซอฟท์แวร์

Technical Debt กับการล้มละลายของซอฟท์แวร์

ผมยกให้โพสนี้เป็น Post of the day ของเมื่อวานเลย ผมชอบมาก มันสะท้อนสถานะการจริงได้ดี แสดงผลกระทบจากการที่ Developer ไม่สามารถเข้าไปมีส่วนในการกำหนดระยะเวลาในการพัฒนางานได้ ทำให้เกิดการเผางาน ลูกค้าอาจได้งานเร็วดังใจ แต่มันเหมือนระเบิดเวลาที่พร้อมจะทำให้ทุกอย่างพินาศในอนาคต สุดท้ายโพสนี้ได้นำเสนอวิธีการแก้ปัญหาที่สามารนำไปปรับใช้ได้ตามสถานะการณ์ได้อีกด้วย

ที่มา https://medium.com/the-way-it-should-be/efb39c7b7699

การล้มละลายของซอฟท์แวร์

How to Avoid “Technical Bankruptcy”

The Way It Is

Manager: “เรื่องเชื่อมต่อธนาคาร ABC จะเสร็จวันไหนครับ?”

Junior Developer: “น่าจะศุกร์หน้าค่ะ”

Manager: “ช้าไปอะครับ พี่บอกลูกค้าไปแล้วว่าเราจะจ่ายเงินผ่านธนาคาร ABC ได้วันศุกร์นี้ ถ้าเสร็จไม่ทันมีหวังลูกค้าไม่จ่ายเงินงวดที่เหลือแน่”

Junior Developer: “แต่หนูคิดว่าถ้าจะทำให้ดีมันต้องใช้เวลานิดนึงอะค่ะ เพราะว่า …”

Manager: “พี่ขอนะรอบนี้ ทำอะไรที่มันง่ายๆไปก่อนได้มั้ย พี่ไม่อยากมีปัญหากับลูกค้า รายใหญ่ซะด้วยครับ”

Junior Developer: “อ่อ ค่ะ”

Manager: “ได้นะ เสร็จศุกร์นี้เลยนะ”

Junior Developer: “ค่ะ”

The Way It Should Be

เหตุการณ์ที่เกิดขึ้นรายวัน บทสนทนาแบบนี้มักจบลงด้วยชัยชนะของผู้มีอำนาจมากกว่าซึ่งส่วนใหญ่ก็จะเป็นคนที่มาจากหน่วยงานธุรกิจ ด้วยความไม่รู้หรือความละเลยก็ตามแต่พวกเค้ากำลังก่อ “หนี้ทางเทคนิค” (Technical Debt) ขึ้นมา

“หนี้” โดยธรรมชาติคือการที่เรายอมแลกสิ่งที่ต้องการในระยะสั้นกับภาระที่ตามมาในระยะยาว เช่น การกู้เงิน เราได้เงินมาใช้วันนี้โดยแลกกับภาระทางการเงินที่ผูกพันในระยะยาว ความน่ากลัวของหนี้คือเราไม่ได้ใช้คืนแค่สิ่งที่เราได้มา แต่เราต้องจ่ายมากกว่านั้นในรูปแบบของ “ดอกเบี้ย” ที่เติบโตขึ้นทุกวันไม่ว่าเราจะจ่ายเงินต้นคืนหรือไม่ แล้วถ้าวันหนึ่งเราหมดปัญญาจ่ายหนี้เราก็จะ “ล้มละลาย”

ถ้าคุณ Manager ไม่รีบร้อนตัดบทไปซะก่อน … บทสนทนาข้างบนจะมีเนื้อหาเพิ่มเติมแบบนี้

  • ทางเลือกที่หนึ่ง: 5 แต้ม (สำหรับระบบเชื่อมต่อธนาคาร ABC) ตอนนี้ หลังจากนั้น 21 แต้ม (เพื่อการทำ Refactoring ใน Sprint หน้า) แล้วหลังจากนั้น 1 แต้มสำหรับทุกๆการเชื่อมต่อกับธนาคารใหม่ๆ … ทางเลือกนี้จะทำให้เราส่งมอบงานให้ลูกค้าได้ตามเวลาและมีระบบที่ยืดหยุ่นเพียงพอเพื่อรองรับความต้องการในอนาคต
  • ทางเลือกที่สอง: 21 แต้ม (สำหรับระบบเชื่อมต่อธนาคารที่สมบูรณ์) หลังจากนั้น 0 แต้มเลยสำหรับการเชื่อมต่อธนาคารใหม่ๆ … ทางเลือกนี้คือการยอมรับความเสี่ยงที่จะส่งงานล้าช้าแต่เราจะมีระบบที่สมบูรณ์แบบมากในการรองรับความต้องการในอนาคต
  • ทางเลือกที่สาม: 5 แต้ม (สำหรับระบบเชื่อมต่อธนาคาร ABC) ไม่มีการทำ Refactoring ใดๆ การเชื่อมต่อกับธนาคารอื่นๆในอนาคตอาจจะเป็น 8, 13, 21 แต้ม จนถึงจุดหนึ่งที่โค๊ดมันไปไม่ได้แล้วก็ต้องมีการทำ Refactoring / Rearchitect ครั้งใหญ่ซึ่งตอนนั้นก็คงประมาณ 100+ แต้ม … ทางเลือกนี้เราจะส่งมอบงานได้ตรงเวลาแต่ต้องใช้เวลามากขึ้นเรื่อยๆกับการเชื่อมต่อธนาคารใหม่ๆ

ทางเลือกที่ดีที่สุดคือทางเลือกที่หนึ่งแต่ทางเลือกที่ได้รับความนิยมที่สุดคือทางเลือกที่สามเพราะสิ่งที่คุณ Manager ต้องการคืองานต้องเสร็จศุกร์นี้มันจึงเป็นทางเลือกเดียวที่เค้ามองเห็น … ช่างน่าเศร้าใจยิ่งนัก

เราจะทำอย่างไรเพื่อหลีกเลี่ยงทางเลือกที่สาม?

  1. ถามคุณ Manager ก่อนเลยว่า “พี่คะ พี่เข้าใจคำว่า ‘Technical Debt’ มั้ย?” ถ้าไม่เข้าใจก็อธิบายถึงผลกระทบให้เค้าฟังไป … สาเหตุหนึ่งที่ทำให้เรามีหนี้สินพะรุงพะรังก็เพราะคนที่มีอำนาจไม่เข้าใจคำว่า Technical Debt ไม่เข้าใจของผลกระทบที่จะตามมาของการตัดสินใจแบบลวกๆของเค้า และชอบคิดว่าอะไรๆก็ง่ายไปหมด
  2. จากข้อหนึ่ง … พยายามอย่าให้คุณ Manager มาคุยเรื่องแบบนี้กับ Junior Developer … น้องเค้ายังเด็ก หัวอ่อน ไม่กล้าเถียงผู้ใหญ่ (ฮ่าๆ) และอาจจะมีความเข้าใจและประสบการณ์ในโค๊ดไม่มากพอจะจัดการบทสนทนาเรื่องนี้ได้ดี เราต้องเป็นกำแพงให้ทีม เราต้องมีจุดยืนที่ชัดเจน
  3. ทุกครั้งก่อนที่เราจะก่อหนี้ เราต้องรู้ว่าเราจะใช้หนี้อย่างไรและเมื่อไร การเป็นหนี้ไม่ใช่เรื่องไม่ดีเสมอไปตราบใดที่เราพิจารณาอย่างรอบคอบและมีวินัยที่ดี มองการมี Technical Debt เหมือนเราเข้าครัวทำกับข้าว ช่วงที่หั่นผักหั่นเนื้อเราก็โอเคที่จะปล่อยให้มันมีขยะรกๆอยู่บนเขียงบ้าง แต่หลังจากผัดข้าวเสร็จเราก็เก็บล้างให้ครัวสะอาดเอี่ยมเหมือนเดิม … ประเด็นสำคัญที่สุดคือเราต้องมีวินัย

Technical Debt vs. Cooking

Technical Debt ก็ไม่ต่างจากการเป็นหนี้ทางการเงิน เริ่มต้นมันอาจจะไม่ใช่ภาระอะไรมากแต่ถ้าเราติดนิสัยก่อหนี้ยืมสินไปเรื่อยๆ ถึงวันนึงมันก็จะมาถึงทางตัน ซอฟท์แวร์ของเราก็จะล้มละลาย … อย่าปล่อยให้เป็นแบบนั้นเลยครับ

Categories
Design UX

ความรู้สำหรับดีไซน์เนอร์มือใหม่

ทีแรกว่าจะแปล แต่ไม่แปลดีกว่า เสียเวลาเกินไป สรุปคือ เค้าอธิบายตั้งแต่ DPI, PPI, ขนาดของจอภาพต่างที่มีผลต่อการออกแบบ, @2x, การตั้งค่าทั่วไปท่ควรรู้ ไปจนถึงเครื่องมือที่เค้าแนะนำ

http://sebastien-gabriel.com/designers-guide-to-dpi/

Categories
Design UX

คำศัพท์ Usability และ User Experience (UX)

เก็บไว้อ่านและศึกษา เวลาอ่านหนังสือหรือว่าคุยกับคนที่ทำงานสายนี้จะได้เข้าใจศัพท์ของเค้ามากขึ้น

http://blog.usabilla.com/the-abc-of-usability/

Categories
การพัฒนาซอฟท์แวร์

บัญญัติกฏ

เกิดอยากจะลองท้าทายตัวเองซะหน่อย เพื่อให้เขียนโค้ดให้ดี อ่านง่าย เป็นระเบียบ เลยไปหากฏมาตั้งให้ตัวเองทำตาม

กฏ 4 ข้อของ Sandi Metz

  1. Class ห้ามยาวเกิน 100 บรรทัด
  2. Method ห้ามยาวเกิน 5 บรรทัด
  3. ห้ามส่ง Parameter เกิน 4 ตัว ถ้าเป็น Object ก็อย่าให้เยอะนัก
  4. ใน Controller ต้องสร้าง Object เพียงตัวเดียวสำหรับรับ Request ไปทำให้เสร็จ

กฏของ Curly

  1. Don’t Repeat Yourself (DRY)
  2. Once and Only Once
  3. Single Point of Truth

หากทำตามกฏ 3 ข้อของ Curly จะนำไปสู่ SRP: The Single Responsibility Principle

Categories
Design UX

มันไม่ง่ายเลยที่จะออกแบบ UX ที่ดี

การที่จะสร้างอะไรซักอย่างที่ให้  UX ที่ดีแก่ผู้ใช้ได้นั้น ต้องใช้ความรู้มากมายหลายสาขา คิดในหลายแง่มุม ต้องทดลองและปรับเปลี่ยนมากมาย แต่ถ้าเริ่มด้วยการใส่ใจ ผมว่าไม่มีอะไรยากจนเกินไป

10465427_10204482695014187_1933799007949620547_o