แปลง multiple JSON object string ด้วย Python

สมมติว่าเรามี JSON object หลายๆ ตัวซ้อนกันอยู่ใน string แบบนี้ (multi line ด้วยอ่ะ ไม่งั้นล้นหน้า page wordpress)

json_string = = """
{"ID":1,"Key":{"Name":"A", "Surname":"A1"},"Pets":["Cat","Dog"]},
{"ID":9,"Key":{"Name":"Z", "Surname":"Z3"},"Pets":["Fish"]}
"""

ถ้าเรา convert มันให้กลายเป็น JSON object (จริงๆ คือ Python dict object) ด้วย json.loads(string) ตรงๆ ผลลัพท์ที่ได้จะบึ้มดังนี้

import json

json_string = = """
{"ID":1,"Key":{"Name":"A", "Surname":"A1"},"Pets":["Cat","Dog"]},
{"ID":9,"Key":{"Name":"Z", "Surname":"Z3"},"Pets":["Fish"]}
"""

json_obj = json.loads(json_string)

>>> Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "...\lib\json\__init__.py", line 354, in load
s
    return _default_decoder.decode(s)
  File "...\lib\json\decoder.py", line 342, in decod
e
    raise JSONDecodeError("Extra data", s, end)
json.decoder.JSONDecodeError: Extra data: line 1 column 65 (char 64)

ทางแก้คือเราต้องทำให้ string ก้อนนั้นเป็น JSON array แล้วเราจะได้ array ของ JSON object มาวนแต่ละตัวได้

import json

json_string = """
[
    {"ID":1,"Key":{"Name":"A", "Surname":"A1"},"Pets":["Cat","Dog"]},
    {"ID":9,"Key":{"Name":"Z", "Surname":"Z3"},"Pets":["Fish"]}
]
"""

json_obj = json.loads(json_string)

print(json_obj[0])
>>> {'ID': 1, 'Key': {'Name': 'A', 'Surname': 'A1'}, 'Pets': ['Cat', 'Dog']}

print(json_obj2[1])
>>> {'ID': 9, 'Key': {'Name': 'Z', 'Surname': 'Z3'}, 'Pets': ['Fish']}

ป.ล. string ถ้าไม่ multi lines ก็ใช้วิธีเดียวกันนั่นแหละ

ป.ล. 2 เพิ่งเห็นว่าเจ้า Gutenberg editor นี่ช่องให้ code ไม่มีรองรับ code syntax, formatting โคตรกากกกกกก ห่วยกว่าเก่าอีก

Quick Note: TypeScript

เพิ่งเจอลูกค้าใช้ภาษา TypeScript (Wiki) เห็นว่าน่าสนใจเลยลองศึกษาดูสักพักล่ะ

  • มันเป็นภาษา Super Set ของ JavaScript ที่คิดค้นโดยเทพ Anders Hejlsberg
  • เพราะว่า JS มันโคตร flexible จนเราเขียนให้มันผิดพลาดได้ง่ายๆ TypeScript ก็เลยแก้ปัญหาด้วยการเพิ่มความเป็น Static Type, Scope, Class-based OOP เข้าไปใน ECMAScript syntax แล้ว compile ออกมาเป็น JS หรือ ECMAScript ver ต่างๆ ได้เลย ปัญหาพวก type ก็ detect กันตอน compile นี่แหละ
  • เพราะมันเป็น Super Set ของ JS ดังนั้นเราเขียน JS ใส่มันไปดื้อๆ ก็ compile ผ่าน
  • ถ้าทำงานกับทั้งภาษา Dynamic กับ Static Type พร้อมๆ กันแล้วจะรู้สึกว่ามันเป็นธรรมชาติมาก ดูไม่ฝืนความเป็น JS แต่ถ้าทำงานกับภาษา Dynamic ล้วนน่าจะชอบ CoffeeScript มากกว่า
  • โดยรวมทำให้เขียน code ช้าลงนิดนึง แต่ได้ความมั่นใจเรื่อง type, การเขียน class แบบที่คุ้นเคยมา
  • ข้อเสียคือเวลาทำงานกับ JS library อื่นๆ มันต้องการ file definition (.ts.d หรือ typing) ที่ระบุ structure ของ function, class, type, module ของ library นั้นๆ เพื่อให้มัน compile ผ่าน (อารมณ์ .h ของภาษา C)
  • ถ้าเป็น lib ดังๆ แบบ jQuery, Angular, React พวกนี้มีคนทำ file พวกนี้ให้อยู่แล้ว แต่คำถามที่สำคัญคือบางคนทำ file พวกนี้ก็ไม่ใช้คนที่เขียน lib นั้น ดังนั้นก็ต้องดูกันยาวๆ ว่าจะไล่แก้ file definition ตาม update ได้ตลอดไหม
  • ถ้าเป็น lib internal (หรือ legacy) lib เนี่ยยากสุดๆ ที่จะมีเจ้า file นี้หรือเขียน file นี้้ย้อนหลัง ขนาดจะลองกะ JS API ตัวเองยังต้องไปเอา file นี้จากลูกค้า (ซึ่ง decompile API ผมออกมาเขียนไอ้ file นี้) มาใช้เลย
  • ส่วนตัวคิดว่าถ้าเป็น Project ใหม่ + ใช้ lib ที่สนับสนุน TypeScript (เช่น Angular 2) หรือ lib ที่เราเขียนใหม่เองก็น่าสนใจที่จะใช้มัน
  • แต่ถ้าทำงานกับ legacy lib เยอะๆ ก็… ตัวใครตัวมัน

ป.ล. กำลังหัดอยู่จาก link TypeScript Tutorial เข้าใจง่ายดี

Git

ช่วงนี้เพิ่งลองใช้ git หลังจากมี account github มานาน ปกติไม่ได้ใช้ version control เพราะว่า code ทำงานอยู่คนเดียว (ส่วนใหญ่ก็ example code มา replicate ปัญหาลูกค้า)

หลังๆ เริ่มมีงานที่รู้สึกว่าถ้ามี version control น่าจะสะดวกขึ้น อย่างน้อยทำอะไรพังก็แก้กลับไป ver เก่าได้ง่ายขึ้นไม่ว่าจะเป็นงาน code, งานเอกสาร ก็อุตสาห์ไปลงเรียน git ที่คนใน office สอน แต่ตอนใช้จริงยังงงๆ อยู่ คือเพราะใช้เองอยู่คนเดียว push ขึ้น remote ก็ push ขึ้น gitlab ของ office ซึ่ง repo นั้นก็มีผมก็ใช้คนเดียว – -”

  • ตอนนี้ยังงงว่าควรจะ add กับ commit ตอนไหน คือ code แล้ว add เลยรึเปล่า เทสผ่านค่อย commit หรือว่า commit แล้วค่อยเทส งง
  • ตอนนี้ใช้วิธี code –> test –> add –> commit อยู่
  • เนื่องด้วย remote repo มีผมใช้อยู่คนเดียว ก็เลยไม่ค่อยเข้าใจการ pull, fetch ซักเท่าไหร่นัก
  • ยังไม่ค่อยแตก branch มากเท่าไหร่นัก ต้องลองเล่นอันนี้ให้เยอะๆ กว่านี้จะได้ลอง merge ด้วย
  • ตอนนี้ยัง set ให้คนอื่นมา clone repo ของตัวเองใน gitlab ที่ office ยังไม่ได้เลย (ฮาาา)
  • วันสองวันนี้วุ่นกับการ set ssh, git ให้ต่อทะลุ proxy บริษัทออกไป github รู้สึกสนุกดี

รู้สึกยังมีช่องว่างที่ยังไม่เข้าใจอีกมากมายให้เรียนรู้ แม้จะช้ากว่าคนอื่นเขาหลายปีแสงก็ตาม