Monthly Archives: January 2013

Mac workflow: Open source URL, v2

A probléma

Leszedtél egy file-t valahonnan, a browser beletette a file metaadatai közé, hogy honnan kotortad azt elő a neten és most vissza kellene találnod a forráshoz.

A megoldás

Korábban ezt megcsináltuk Thingiverse-specifikusra, de nem tetszett, hogy a script önkényesen dönt, hogy nekem épp melyik URL kell, ezért faragtam belőle popup menüset, amivel Te választhatsz, hogy melyik metában tárolt URL-t nyissa a Safari. Lustáknak itt a bezippelt workflow, aki meg olvasgatná itt a postban a forrást az ide nézzen:

on run {input, parameters}
 
	set theFile to (input)
	set aFile to quoted form of POSIX path of theFile
	set theURL to (do shell script "mdls -name kMDItemWhereFroms -raw " & aFile)
 
	if theURL is "(null)" then -- no attribute
		set theURL to "(URL info not found)"
		set theMessage to ""
	else
 
		set URLs to {}
		repeat with i from 1 to the count of paragraphs of theURL
			set p to paragraph i of the theURL
			set firstQ to findFirst(p, "\"")
			set lastQ to lastOffset(p, "\"")
 
			if firstQ > 0 and lastQ > 0 and (lastQ - firstQ > 1) then
				copy characters (firstQ + 1) through (lastQ - 1) of p as string to q
				set end of URLs to q
			end if
		end repeat
 
		set selectedURL to false
		if (count of URLs) = 1 then
			set selectedURL to (item 1 of URLs)
		else if (count of URLs) > 1 then
			set selectedURL to (choose from list URLs with title "Open URL" with prompt "Select URL to open:" without multiple selections allowed)
		end if
 
		if (selectedURL is not false) then
			tell application "Safari"
				tell window 1
					set current tab to (make new tab with properties {URL:selectedURL as text})
				end tell
			end tell
		end if
	end if
	return input
end run
 
on findFirst(str, findString)
	-- HAS (http://applemods.sourceforge.net/mods/Data/String.php)
	local str, findString, len, oldTIDs
	set oldTIDs to AppleScript's text item delimiters
	try
		set str to str as string
		set AppleScript's text item delimiters to findString
		considering case
			set len to str's first text item's length
		end considering
		set AppleScript's text item delimiters to oldTIDs
		if len is str's length then
			return 0
		else
			return len + 1
		end if
	on error eMsg number eNum
		set AppleScript's text item delimiters to oldTIDs
		error "Can't findFirst: " & eMsg number eNum
	end try
end findFirst
 
on lastOffset(the_text, char)
	try
		set i to 1
		set last_occurrence to 0
		repeat count of the_text times
			if item i of the_text as string = char then
				set last_occurrence to i
			end if
			set i to i + 1
		end repeat
	on error
		return 0
	end try
	return last_occurrence
end lastOffset

A hordozható adattárolókról

Egy ideje tervezem ezt a bejegyzést megírni. Ma reggel láttam Józsi ajánló posztját, így azt gondoltam, pont passzolna mellé a dolog, úgyhogy vágjunk bele!

Ha a Macintoshodon külső storage-ről szeretnél adatot elérni, az alábbi interfészek állnak rendelkezésre:

  • optikai meghajtó - nem jó. Kicsi, elavult, sérülékeny, lassan írható.
  • SD kártya - majdnem oké. Nem a leggyorsabb és a relatíve nagy kapacitás még drága, de kicsi, univerzális és viszonylag jól bírja a gyűrődést.
  • USB2 - lassan már nem oké. A leguniverzálisabb, de ahogy nő a storage igény, úgy érzed egyre lassabbnak. Cserébe viszont lassan a kávéfőzőn is van USB slot.
  • FW800 - nem oké. Sebességben veri az USB2-t, viszont minden ilyen csatlakozóval ellátott eszköz megkapja az AppleTaxot, amit a "buziAlmás" felhasználó fizet meg. Ezért cserébe a penetrációja is sokkal kisebb.
  • Gigabit Ethernet és WiFi - nem oké. Kevés a sebességük.
  • USB3 - oké. A sebesség már az, ami tisztességesnek mondható a mai (=2013-as) mércével, eszköz van bőven, az ár is megfelelő, viszont az Apple csak 2012 táján kezdett neki a 2008-ban tervezett standard implementálásának.
  • Thunderbolt - oké. A sebesség brutális, a szabvány tartalékai szintén, ám itt minden eddiginél irgalmatlanabbul súlyt le az AppleTax: az amúgy is méregdrága Thunderbolt csatolós eszközökhöz a gyártó licencspórolási céllal nem mellékeli a Thunderbolt kábelt, ami a usernek akár 10kHUF nagyságrendű újabb lehúzást is jelenthet (lásd a printerkábelek kispórolása anno, csak ez ma még gusztustalanabb mértékben megy).

A teljesség kedvéért: fentiekhez non-Apple világban csapódna még az eSATA.
Megvan a lista, nem is elemezgetném, hanem inkább elmondom az általam talált megoldásokat.

The Nifty MiniDrive

Kickstarter project. A lényege, hogy a ma már minden Mac notebookon jelen levő SD kártya slotba egy olyan micro SD kártya foglalatot gyártsanak, ami teljesen belesimul a gép síkjába:

Micro SD kártyák jelenleg 256 GB kapacitásnál tartanak (igaz eddig csak noname-ben láttam ekkorát, a SanDisk 64 gigánál tart).
A Kickstarter project 2012 augusztus elején zárult, az utolsó infók szerint 2013 január végén indul a szállítás.

Seagate FreeAgent GoFlex Thunderbolt Adapter

A Seagate a hordozható GoFlex HDD családjához fejlesztette ezt a Thunderbolt adaptert:

thunderbolt-portable-adapter

Noha erről a gyártó sehol nem tesz említést, az adapter természetesen egy közönséges 2.5"-os SATA HDD csatlakozó. Ennek megfelelően bármilyen vele kompatibilis storage-et rádughatsz, nem kell annak GoFlex dobozban lennie. Egy tetszőleges méretű SSD-t ráapplikálva lényegében lebomlanak a sebességhatárok és brutális teljesítményű mobil adathordozót kaptál a kezedbe. Just think about it.

3D nyomtatás: az Apple Lightning connector esete az Ultimakerrel

Az apró mütyürök nyomtatásakor legtöbbet az illesztések méretváltozásaival kell megküzdenem. Jó példa erre az új Apple Lightning csatlakozónak szánt furat esete - nézzük is meg!

Az átlátszó tokban lakó iPhone 5 számára szerettem volna gyártani egy bármire felcsavarozható dokkot. A töltőkábel befogatását ugyanúgy szerettem volna megoldani, ahogy anno a Brodit dokkolót módosítottam. Ilyen lett az ojjektum:

iPhone5-screwable-dock-model

A kábelvezető lyuk elkészítéséhez szépen kimértem a Lightning csatit: egy 7.7x4.6mm-es, lekerekített sarkú téglalapba pont passzolni fog.Mivel korábban is megküzdöttem már az extruder nyomtatásból fakadó kisebb pontatlansággal, ezért azt gondoltam, jó ötlet, ha csak felkerekítem egész mm-ekre a befoglaló téglalapot és csinálok egy 8x5 mm-es, 2.5 mm-re kerekített lyukat. Meg is csináltam, "okosan" beleterveztem a modellbe, majd nyomtattam egy egy és háromnegyed órásat - íme az eredmény:

lightning-hole1-too-tight

A Lightning csatinak szűk lett a járat.
Még ekkor sem jött meg az eszem, hanem inkább gyártottam egy 9x7 mm-es furatot. Persze ezt is rögtön a modellbe, újabb ~100 perc elpazarlásával:

lightning-hole2-too-loose

A csati most már elfért a vájatban, csakhogy az most meg mindkét irányban túl bőnek bizonyult, ettől pedig elfordulhat a csatlakozó, ami nagyon nem jó. Harmadik nekifutásra megjött az eszem és legyártottam egy 1 mm vastag kis lapkába az újabb furatot, ezúttal 8.5x5.5mm méretben:

lightning-hole3-too-loose

Az eredmény ismét egy laza vájat, de már közeledtünk az igazihoz. Lemértem, hogy mekkora lett a tervezetthez képest a nyílás és csodák csodája, pontosan a CAD-ben beállított méretet láttam a tolómérőn.
Még 0.25 mm-rel csökkentettem a méreteket, a kerekítést 2.63 mm-re vettem, majd jött egy újabb print próba és láss csodát:

lightning-hole4-perfect

A szinte tökéletesre sikerült lyukat visszamérve az derült ki, hogy az 7.7x4.7 mm-esre sikerült, azaz az pontosan akkora, amekkorára szükségem van.

A méretek gonosz ugrándozását a 0.4 mm vastag PLA alapanyag okozza. Sajnos pontos recept nincsen arra vonatkozóan, hogy mekkora tűréssel kellene számolni. A tanulság annyi, hogy a végleges modell tervezése előtt érdemes mintafuratokat készíteni, amelyeket pillanatok alatt kinyomtathatsz és ellenőrizhetsz, hogy a hőn áhított rést mennyire fedi a valóságos izéd.

Mac workflow: Open source URL service

Update: kicsit szebb, v2-es megoldás erre.

Ahogy töltögettem le Karácsony előtt a sok printelni való STL file-t a Thingiverse-ről, egyre többször jött elő, hogy meg kellene újra néznem valamit az STL file-t tartalmazó oldalon újra. Szerencsére OS X alatt a kMDItemWhereFroms metadata attribútumba bekerül a letöltés URL-je, amit én néha meg-meg néztem már korábban is egy vérbuta shell scripttel, ami nálam eddig így nézett ki:

#!/bin/sh
mdls -name kMDItemWhereFroms -raw "$*"

Ez egy zárójelek közé zárt comma delimited URL listát ad vissza. Nekem ebből az URL listából az utolsó kellene (a Thingiverse Amazon S3 storage-et használ, az első URL a storage-ra mutat, míg a második az eredeti Thingiverse oldalra), mégpedig minél kevesebb szüttyögéssel, azaz monjduk egy Service formájában.
Némi rövid googling után dobta a gép a közel konyhakész scriptet a MacScripter oldaláról, már csak hozzá kellett ragasztani az Automator Service script számára szükséges paraméterátvételt és kész is:

property getSpecific : false -- show the specific download URL?
on run {input, parameters}
 
	set theFile to (input)
	set aFile to quoted form of POSIX path of theFile
	set theURL to (do shell script "mdls -name kMDItemWhereFroms -raw " & aFile)
	if theURL is "(null)" then -- no attribute
		set theURL to "(URL info not found)"
		set theMessage to ""
	else
		if getSpecific then -- get the first item (the download URL)
			set theURL to paragraph 2 of theURL
			set here to offset of "\"" in theURL
			set theURL to text (here + 1) thru -3 of theURL -- the download URL
			tell application "Finder"
				set name of theFile to theURL --I have no idea what im doing
			end tell
		else -- get the last item (the page/site URL)
			set theMessage to "page/site "
			set theURL to paragraph -2 of theURL
			set here to offset of "\"" in theURL
			set theURL to text (here + 1) thru -2 of theURL
		end if
 
		tell application "Safari"
			tell window 1
				set current tab to (make new tab with properties {URL:theURL})
			end tell
		end tell
	end if
 
	return input
end run

Ebből nagyjából két klikk az Automator workflow megalkotása, de ha ezzel bajban lennél, akkor

  • konyhakész service zippelt változata leszed innen
  • bemásol a ~/Library/Services/ folderbe, majd ott kicsomagol

Apple Maps for iOS vs Google Maps for iOS IRL teszt

Reggel elmentem a gyerekekért Szegedre és gondoltam csinálok egy adatforgalmi tesztet a két térképalkalmazással - odaúton az Apple Maps, visszafelé a Google Maps dolgozott, az adatot egy iPhone adta personal hotspotként, míg az alkalmazások egy iPad 3-on futottak.

Apple Maps: 1.3 MB sent / 1.6 MB received
Google Maps: 1.6 MB sent / 5.9 MB received

Mit gondoltok, vajon a Google Maps valóban közel négyszer annyi adatot kaphat, vagy esetleg más az adatformátum / tömörítés / etc. és ez okozza a nagy difit?

Visszafelé a város határában elbontottuk a netes kapcsolatot és csak kíváncsiságból másfelé kezdtem el tekeregni az autóval. A Google Maps meglepő módon egész sokat becache-elt a város vektoros térképéből, míg az Apple Maps szinte szigorúan csak azt a területet ismerte, amelyiken az odaúton áthaladtunk.

Még egy tanulságos adalék a teszthez, bár ez erősen perifériafüggő. Az autóba egy Pioneer fejegység van integrálva, amelyhez tartozik egy gyári iPod illesztőkábel. Az út elején erre a kábelre csatlakoztattuk az iPadet, míg egy mezei szivargyújtós töltő töltötte az iPhone akksiját.
Sokáig nem tudtuk mire vélni, hogy mitől bolondult meg az iPad: bármelyik navigációs alkalmazást indítottuk el, mind össze-vissza dobálta a pozíciónkat, fogalmuk nem volt, milyen irányba halad épp az autó. Közel 10 perc küzdelem után jöttünk rá, hogy a problémát a Pioneer CD-IU51V kábele okozza: amint lehúztuk az iPad-ről, a GPS újra magához tért és minden ment simán. Summa summarum, ha ilyen bajod van, mindenképp érdemes a töltőkábelre is gyanakodni.