"Żarówki" Philips Hue są tańsze od klasycznych ;-)

Gdy człowiek pomyśli o zabawie ze smart żarówkami to zwykle ogląda Hue i mina mu lub jej rzednie gdy widzi cenę Hue.
Np. ~350 PLN za 3 "żarówki" 9W, które dają 806lm, i odpowiadają tak mniej więcej 3x 60W.
Cena 1 takiej żarówki to ~117 PLN.

Szczerze nie wiem ile kosztuje zwykła żarówka żarowa 60W, powiedzmy, że 0 PLN dla łatwego rachunku
.
W takim przypadku te początkowe 117 PLN kosztu Hue to 3545 godzin pracy zwykłej żarówki.
W tym czasie Hue spaliłaby dodatkowe 58 PLN...
Mamy więc takie równanie:

117 + x*9/1000*0.55 = x*60/1000*0.55
x*51/1000*0.55=117
x=117/(51/1000*0.55)
x=~4171 h

Mówiąc inaczej po 4172 godzinach użytkowania Hue staje się tańsze.

Czas pracy Hue jest wg producenta szacowany na 25 tysięcy godzin, czas pracy żarówki żarowej to około 15 tysięcy godzin.

W takim przypadku łączny koszt "życia" Hue to 240.75 PLN, co daje trochę mniej niż 1 grosz za godzinę świecenia.
Założyliśmy, że żarówka żarowa nic nie kosztuje, wtedy 15 tysięcy godzin pracy to 495 PLN, czyli 0.033 PLN za godzinę.
Żeby nie było gadania, koszt godziny świecenia przez żarówkę żarową w naszym modelu jest zawsze taki sam, niezależnie od tego czy świeci 15 tysięcy godzin, godzinę czy miliard godzin.

Jakby nie liczy Hue wychodzi ponad 3 razy taniej od zwykłej żarówki żarowej :-)

Podobne posty^beta
To uczucie gdy przechytrzysz elektronikę ;-)
Lampka ;-)
Oszczędzanie
Nie wyłączysz światła jak padnie WiFi....
Tydzień z Google Home

Programowanie z uśmiechem?

Będąc w piątek na występie Cirque du Soleil w San Francisco zauważyłem, że część występujących się uśmiecha gdy robią swoje sztuczki, a część nie.
Czasem nawet 2 osoby robiąc podobne rzeczy rośnie reagują.
I to mnie zawiodło do tego jak ja programuje.
Zwykle się nie uśmiecham gdy programuje, wydaje mi się że ogólnie ludzie w koło też się nie uśmiechają.
Częściej lecą wiązki przekleństw, a później radość pomieszana ze zdziwieniem, że coś działa.
I tak się zastanawiam, czy można by spróbować programować z uśmiechem na twarzy? ;-)

posted from Bloggeroid

Podobne posty^beta
Papierowy GMAIL i Internet z tualety ;-)
Był wrzesień, jest październik
Bad, bad server. No donut for you.
Lepszy soundtrack dla rzeczywistości ;-)
Długi tydzień

Utah Teapot

Byłem dziś w Computer History Museum (w końcu skoro jestem w Dolinie Krzemowej to chyba wypada ;-)) i zrobiłem zdjęcie Utah Tepot ;-)

Jest on o tyle ważny, że od 1975 roku jest używany jako jeden z podstawowych modeli dla grafiki 3D ;-)

Sam go używałem :-)

Ostatnio nawet wróciłem do niego i umiem go animować w JavaScript'cie ;-)


To jest zresztą przykład czegoś co przeszło ze mną chyba najdłuższą drogę w kodowaniu ;-) Najpierw napisałem to w C i assemblerze, później przeniosłem do Java'y, a w końcu do JavaScript'u ;-)


Podobne posty^beta
A imię jego 44....
Kto się zna na obróbce grafiki?
Ulotny twór - software ;-)
No i chyba wyleczyłem EEE Pad Transformera z mega czkawki
Chcę do Ameryki ;-)

Oceny w Uberze

Właśnie jadę Uberem z Foster City do Mountain View.
Samochód jest taki sobie i zastanawiam się czy to jest powód by dać 4 gwiazdki zamiast zwyczajowych 5?
Cześć kierowców się bardzo stara, mają ładowarki dla klientów, do tego są w stanie nawet puścić Ci muzykę jakiej chcesz i w ogóle są mili. Do tego mają odpicowane auta, inni podchodzą do tego tak, że idą programem minimum.
I nie wiem czy jak ktoś się nie stara do wypada takiemu komuś dać 4 gwiazdki?
W końcu to jest człowiek i takie coś może wynikać nie z bycia gorszym człowiekiem, a po prostu z kłopotów w tym zakresie.
Czy danie komuś 4 gwiazdek za to, że go i jego samochodu po prostu nie lubię jest OK?
Ta cała gig economy jest trudna....

posted from Bloggeroid

Podobne posty^beta
Zuchwała kradzież godziny
Brudny sekret ;-) czyli jak podnieść oceny aplikacji w Google Play ;-)
"Cześć"
Nie takie złe API ;-)
Hackowanie człowieków - kiedy?

Java Profiler jak to działa?

W życiu każdego człowieka który programuje (zwiemy ich programistami i programistkami) nadchodzi taki dzień, że trzeba coś przyspieszyć, bo coś wolno działa i nie do końca wiadomo dlaczego.
Wtedy wzrok takiego kogoś pada na profiler.
Który to profiler obiecuje, że wskaże nam miejsca gdzie nasz kod spędza najwięcej czasu.

Oczywiście zwykle wyniki z profilera nie są tym czego byśmy oczekiwali ;-) bo my byśmy chcieli jasnej informacji, że problem jest w danej linii, a zamiast tego dostajemy informację, że 90% czasu spędzono w metodzie doSth() ;-)

Ale nie o tym tutaj, a o czymś innym.
Zastanawialiście się kiedyś jak działa profiler? :-)

Ja zawsze myślałem, że używa jakichś sprytnych mechanizmów JVM, które mówią ile czasu trwało wykonanie danej metody i że tak naprawdę profiler robi tylko za interfejs do JVM.
Albo, że profiler modyfikuje kod i dodaje swój bytecode do mierzenia czasu...

W tym drugim miałem nawet trochę racji ;-)

A jak jest naprawdę? ;-)

Okazuje się, że profiler zwykle wcale nie wie ile czasu spędzono w metodzie czy metodach, ale używa sprytnej sztuczki by ten czas estymować.

Wiemy, że w Java'ie mamy wątki zwane też Thread'ami.
Mamy też Stack Trace, w którym każda ramka opisuje "linię" kodu w której jest JVM w danej metodzie. Ze Stack Trace'a możemy dowiedzieć się która metoda woła którą.
Zwykle Stack Trace'a widzimy w momencie gdy leci jakiś wyjątek i Stack Trace pozwala nam wyśledzić to miejsce.

Mamy też coś takiego jak Thread Dump, czyli zrzut stanu w postaci StackTrace + stan aktywności dla każdego z wątków.

I właśnie Thread Dump jest kluczowym elementem działania Profilerów ;-)

Profiler "po prostu" prosi z zadanym interwałem JVM o Thread Dump'y i zapisuje je sobie.
Dzięki temu dostaje "historię" tego gdzie dany wątek był w zadanym czasie.

Profiler używając Thread Dump'a próbkuje stan JVM i dzięki tym próbką może pokazać nam gorące fragmenty kodu, w których spędzamy najwięcej czasu*.

Ponieważ Thread Dump jest dość ciężką operacją to w trakcie profilowania prędkość całej aplikacji nam maleje, ale oznacza to też, że istnieje pewna "graniczna" częstotliwość próbkowania, a więc i to, że dokładność/rozdzielczość profilera jest ograniczona.
Stąd profiler może gubić pewne bardzo krótkie metody, albo mocno niedoszacowywać ilość ich wywołań. Co zwykle nie powinno być problemem, bo jeśli robimy 100 zrzutów na sekundę, a metodę wołamy milion razy i ani razu z wciągu tych 100 zrzutów nie byliśmy w tej metodzie to raczej nie ona stanowi nasz problem (ten fragment jest bardziej pisany w oparciu o intuicję niż fakty).

Tu istnieje teoretyczna metoda na poprawienie rozdzielczości, choć szczerze nie wiem czy jest stosowana (tzn. wiem, że jest stosowana np. w AppDynamics, więc pewnie DynaTrace i podobne narzędzia do monitorowania aplikacji też to mogą zrobić, ale w AppDynamics to jest robione "ręcznie" i raczej jest pomyślane jako mechanizm do zbierania metryk biznesowych czy technicznych z aplikacji, a nie metoda na profilowanie per se).
Otóż JVM pozwala na dodanie agenta, który w trakcie ładowania klas może dodać do tych klas swój kod. Jednym ze sposobów jest dodanie kodu na początku i na końcu metody. Ten kod może np. zapisywać informacje o czasie wykonania metody, albo o ilości wykonań metody.
Oczywiście technika ta ma też swoje wady. Bo trudno powiedzieć wtedy jaki procent czasu wykonania danej metody to wykonanie samej metody, a jaki to czas wykonania kodu mierzącego czas i zbierającego statystyki ;-)

Przyznam, że gdy w końcu dowiedziałem się jak działają profilery to trochę spadła mi wiara w ich skuteczność ;-) Nadal są świetnymi narzędziami, ale jednak nie magicznymi.
Wydaje mi się jednak, że teraz jakoś lepiej umiem korzystać z ich wyników.

A i jak potrzebujecie w normalnym życiu programisty czy programistki zajrzeć aplikacji w bebechy to fajnie jest użyć Java Mission Control. Fakt, sam używałem w celach "profilowych" Java Mission Control tylko w Java 8 i nie wiem do końca jak jest z licencją na JCM i jej dostępnością w Java 11...
Ale dzielę się tutaj przydatnymi opcjami do uruchamiania Java'y które w razie obecności JCM zapiszą nam śliczne pliki, które możemy obejrzeć w JCM**.

Poniższy zestaw opcji dla Java'y zapisuje FlightRecord do pliku rec.jfr
-XX:+UnlockCommercialFeatures -XX:+FlightRecorder -XX:FlightRecorderOptions=dumponexit=true,dumponexitpath=rec.jfr -XX:StartFlightRecording=defaultrecording=true


(to wyżej to kopia z moich notatek z Notion (wcześniej z Evernote))

* - OK, tak naprawdę może pokazać nam też punkty, które nie są gorące, ale np. wątek tam na coś czeka, np. na sieć.
** - uwaga, Oracle coś spaprało i na Java 8 UI do JCM nie działa na macOS, stąd dobrze mieć jest do oglądania zapisów z JCM gdzieś 1.8.0_96 czy podobną.


Podobne posty^beta
Sztuczki tropiciela błędów, part 2 ;-)
Zinwigiluj się sam ;-)
Raport z emigracji ;-)
wait() i notify()/notifyAll() - najbardziej nierozumiane metody klasy Object ;-)
Inercja i koło wielokrotnego wynajdywania, czyli radosne macki piekieł w kodzie [alem pojechał w tytule ;-)]

"Pokolenie nihilistów"

Podobno abp (arcybiskup?) Wiktor Skworc w swojej homilii zaapelował do MEN o regulacje które zapewnią, że uczniowie będą musieli chodzić na lekcje religii albo etyki. Bo wg niego brak takiego wykształcenia skutkuje "pokoleniem nihilistów".

Nie chodziłem na religię, ani etykę.

Czy jestem przedstawicielem pokolenia nihilistów?

Co do dobra i zła uważam, że nie istnieją absolutne dobro i zło, bo w mojej ocenie dobro i zło wynikają tylko z oceny przez jakiś subiektywny byt.
Coś co wg mnie jest dobre lub złe, ktoś inny może ocenić inaczej.

Mamy pewne ewolucyjne i społeczne definicje dobra i zła i dobrze nam służą, i póki ktoś nie jest psychopatą czy socjopatą to raczej większości z nich przestrzega.

Stąd pytanie, zakładając, że pan arcybiskup ma rację. Co złego w "pokoleniu nihilistów"?

Podobne posty^beta
Najmocniejszy "żart" Prima Aprilisowy
Dobro i sprawiedliwość
Edukator ;-)
No to w fajnym kraju żyjemy
Frustracja....

A może by tak nosić drugi telefon specjalnie do on-call'a?

Trafiłem znów na on-call'a ;-) po 3.5 roku błogiego bycia bez on-call'a, znów go będę miał...

Tym razem używamy aplikacji, która zowie się PagerDuty.

Z drugiej strony, ostatnio zacząłem odkrywać uroki trybu samolotowego w telefonie, bo nagle nie ma się tych wszystkich powiadomień*

Ale nie wypada włączać trybu samolotowego, gdy PagerDuty chce gadać i sprawdzać czy czasem nie ma jakichś problemów z naszymi zabawkami.

Stąd powoli w głowie rodzi mi się pomysł noszenia 2 telefonów gdy jestem na on-call'u :-)
Jeden bym skonfigurował z PagerDuty, firmowym Slackiem i takimi sprawami, a drugi byłby tylko z moimi zabawkami**

Zawsze mam najmniej 2 w miarę dobre telefony w domu i zaczyna mnie kusić taki układ...


* - tak, wiem, że można je wyłączyć, większość mam wyłączoną, ale przez to co jakiś czas mnie kusi żeby sprawdzić czy np. ktoś do mnie na Telegramie nie pisze, albo na WhatsApp.
** - teraz mam tylko PagerDuty zainstalowane z firmowych rzeczy, nawet nie mam firmowego WiFi włączonego.

Podobne posty^beta
Zgubiłem dźwięk...
On-call....
Ostatni on-call ;-)
Wybory mi poprawiły humor ;-)
Idą wybory i mnie kusi wprowadzenie mojej własnej ciszy około wyborczej ;-)

Nintendo Switch - jednak nie...

Kupiłem jakiś miesiąc temu....

I to jednak nie dla mnie, przynajmniej na razie.
W pociągu jakoś nie miałem natchnienia by grać, zobaczymy najpewniej za niedługo w samolocie.

Ale jak dla mnie ekran za mały i jednak trzeba czekać.
Co prawda chcą zagrać w Doom'a szybciej jest to odpalić na Switch'u, niż na XBOX'ie, ale to nie jest takie szybkie jakby się wydawało.

Do tego ekran jest jednak dla mnie zbyt mały.

Najdłużej jak na razie grałem w Untitled Goose Game, którą już prawie przeszedłem ;-)

Podobne posty^beta
YouTube czy Vimeo?
Definicja szaleństwa, czyli ja i konsole przenośne
Pożytki z terminu ważności karty kredytowej ;-)
Steam Deck OLED po 24h :-)
Seriale na podstawie gier... na razie 2 się udały ;-)

Pixel 4 XL czy iPhone 11 Pro

Nadchodzi mniej więcej czas kiedy trzeba by się było rozejrzeć za kolejnym telefonem i nie wiem co wybrać.

Brnąć w Pixela 4 XL, czy przejść do obozu Apple i wziąć iPhone 11 Pro?

Kocham Pixela 3 XL za aparat, nienawidzę za baterię.

W ogóle Pixel'e to są dziwne telefony. Jak iPhone zwykle przychodzi jako cały pakiet dobrych rzeczy, które są wśród najlepszych, może nie są najlepsze, ale są wsród najlepszych, to Pixel'e są mieszane.
Mają np. świetną kamerę, ale słabą baterię.
Pixel 3 wprowadził kamerę szerokokątną na przód telefonu, a Pixel 4 ją usunął....

Pixel'e są jak Google, genialne, ale jakieś takie nie do końca przemyślane.
Do tego w Pixel'ach najwięcej rzeczy jest w sofcie i w AI, które działają zwykle tylko dla języka angielskiego i paru innych.

Jest np. możliwość zrzucenia rozmowy na asystenta Google, ale działa tylko w kilku miejscach na świecie.

Apple jest za to dość nudne, ale działa.
Do tego idąc w iPhone'a 11 Pro mogę pójść też w Apple Watch'a....

Podobne posty^beta
70+ godzin, Staff i iPhone ;-)
Pixel 6 po ~2 miesiącach.... prawie nieodróżnialny od Pixela 4 XL ;-)
Google zachorowało na księgowych...
Ważenie Stefanów
Magia....

"os.arch", "os.name", "sun.arch.data.model" co to jest i co pokazuje na jakiej maszynie i OSie? ;-)

[updated 21/02/2021 ;-) niżej dodano wyniki dla Macbooka z M1 :-)]

Ostatnio musiałem dodać do kodu testy, które testują czy interfejs do bazy danych dobrze gada z DynamoDB.
Zdecydowałem, że użyje lokalnego DynamoDB, które dostarcza AWS.
Problem w tym, że drań wymaga natywnych bibliotek na ścieżce...
A kod będzie uruchamiany na macOS, Windows i Linuksie ;-)
Stąd musiałem napisać kawałek, który rozpoznaje którą bibliotekę natywną umieścić na ścieżce.

Tutaj podzielę się czymś podobnym, a mianowicie tym jak różne OSy i czasem platformy sprzętowe się przedstawiają gdy pyta się je o to kim są z Java'y ;-)


Podstawą naszej zabawy będzie ten prosty programik:

public class Test {

    public static void main(String[] args) {
        System.out.println("OS Architecture : " + System.getProperty("os.arch"));

        System.out.println("OS Name : " + System.getProperty("os.name"));

        System.out.println("OS Version : " + System.getProperty("os.version"));

        System.out.println("Data Model : " + System.getProperty("sun.arch.data.model"));

        System.out.println("Endian : "+ System.getProperty("sun.cpu.endian"));
    }

}

Tutaj opis tego co oznaczają poszczególne informacje.

OS Architecture (os.arch) - prostu architektura CPU i OSa (CPU może mieć często wyższą architekturę, ale uruchamiać kod dla "niższej" architektury). W przypadku Java'y będą to teraz głównie amd64 i x86_64 (obie znaczą to samo, ale zależą od OSa), czasem może się zdarzyć arm, z rzadka x86.
OS Name (os.name) -  nazwa OSa, najbardziej "niepewna" część, macOS to np. czasem macOS, a czasem Darwin, Windows to czasem win, a czasem Windows. Jak jednak pokazują rezultaty, ostatnimi czasy jest jakiś porządek tutaj.
OS Version (os.version) - wersja OSa, chyba najmniej przydatna rzecz. Rzadko w Java'ie używamy wersji OSa do detekcji czekogolwiek.
Data Model (sun.arch.data.model) - bitowość Java'y :-) najmniej musi być 32, bo Java nigdy nie występowała w wersja 16 bitowej (przynajmniej nie znam takowej), teraz prawie zawsze 64. Ważna gdy ładuje się biblioteki natywne, bo 32 bitowy kod nie może być wykonany w trybie 64 bitowym, a 64 bitowy w trybie 32 bitowym.
Endian (sun.cpu.endian) - ciekawostka, "indianowatość" CPU. Tu jest ciekawe bo i x86 i ARMy są little endian, a sama Java jest big endian. Ogólnie w przypadku zapisu liczb w CPU, pamięci czy w pakietach przesyłanych siecią (albo w plikach) powstaje pytanie gdzie są które części liczby, czy bajt należy czytać od lewej czy prawej, czy słowo od prawej czy lewej i tak dalej. Kiedyś było to dość ważne, dziś żyjemy w świecie gdzie to wszystko jest zwykle dla nas załatwiane przez OS i biblioteki. Nasze OSy i CPU są little endian, sieć i Java big endian, a mimo wszystko to jakoś działa.

Sam programiki uruchomiłem na kilku konfiguracjach (z czego 3 to mój MBP 15 z macOS Catalina + Parallels 15)

Wyniki są takie:

Linux (Ubuntu 18.04, uruchomione przez Parallels 15 na macOS Catalina)
OS Architecture : amd64
OS Name : Linux
OS Version : 4.15.0-72-generic
Data Model : 64
Endian : little

Windows (Windows 10, uruchomione przez Parallels 15 na macOS Catalina)
OS Architecture : amd64
OS Name : Windows 10
OS Version : 10.0
Data Model : 64
Endian : little

macOS Catalina
OS Architecture : x86_64
OS Name : Mac OS X
OS Version : 10.15.2
Data Model : 64
Endian : little

Raspbian na Rasbperry Pi (Pi 2 Model B)

OS Architecture : arm

OS Name : Linux

OS Version : 4.1.19-v7+

Data Model : 32

Endian : little

Linux (Ubuntu 16.04)
OS Architecture : amd64
OS Name : Linux
OS Version : 4.4.0-170-generic
Data Model : 64
Endian : little

Android (Android Emulator w trybie x86 na macOS Catalina)
OS Architecture : i686
OS Name : Linux
OS Version : 4.14.112+
Data Model : null
Endian : null

Android (Pixel 3 XL z Androidem 10)
OS Architecture : aarch64
OS Name : Linux
OS Version : 4.9.185-xxxxx
Data Model : null
Endian : null

Macbook z M1 (dodane 21/02/2021)

OS Architecture : x86_64

OS Name : Mac OS X

OS Version : 10.16

Data Model : 64

Endian : little

Macbook z M1 (dodane 10/05/2021) - w końcu ARMa raportuje ;-)

OS Architecture : aarch64
OS Name : Mac OS X
OS Version : 11.2.3
Data Model : 64
Endian : little

Jak widać największe zamieszanie panuje w OS Architecture.
Na Windows i Linuksie pryz 64 bitach mamy amd64, ale na macOS X mamy x86_64.
Obie są prawidłowymi nazwami, choć x86_64 było nazwą zaproponowaną przez AMD gdy tworzyli ten tryb dla Athlonów, a amd64 powstało trochę później*.

Jeszcze kilka lat temu problemem była też "bitowość", czyli Data Model.
Wtedy sprawa się komplikowała, bo choć większość CPU na rynku była już 64 bitowa, to jednak OSy nadal były 32 bitowe. Później już i OSy i CPU były 64 bitowe, ale jeszcze soft był 32 bitowy.
Przez jakiś czas dostępne były wersje Java'y dla 64 bitowych OSów, które mogły pracować w 32 i 64 bitach.
Tutaj napiszę z pamięci, bo nie mam nigdzie żadnego 32 bitowego procesora zgodnego z x86, ani 32 bitowego OSa :-)
Ale jeśli dobrze pamiętam dla Windows to był x86, dla Linuksa i386 (czasem i586???), nie mam pojęcia jak było z macOS.
Na szczęście od paru lat wszystko co mamy ma prawie na 100% 64 bity (najnowsze Raspberry Pi 4 też jest 64 bitowe).

Kolejnym problemem jest OS.
Wydaje się jednak, że dziś można niemal na 100% przyjąć, że 1 słowo w lower case pozwoli na rozpoznanie OSa.
Widzimy też, że Android to tak naprawdę Linux ;-)

Oczywiście autorzy natywnych bibliotek nie zawsze przestrzegają reguł, stąd jeśli wiemy, że nasz kod będzie działał np. tylko na 64 bitowych wersjach macOS, Linuksa i Windows to prościej po prostu dokonywać detekcji OS'a i zamiast budować nazwę biblioteki, to po prostu mieć zahardcodowane wersje dla każdego z OSów.
Nie jest to najbardziej uniwersalna metoda, ale kod jest dużo prostszy ;-)

* - historia jest taka, że Intel uznał, że przejście na 64 bity to dobry moment na przejście na nową architekturę. Ale ponieważ była to nowa architektura, konieczna byłaby nowa licencja i dodatkowo trzeba by było tworzyć całkiem nowe procesory. Stąd AMD postanowiło wziąć istniejącą architekturę x86 i ją "zupgradować" do 64 bitów, tak jak kilka lat wcześniej zrobił Intel gdy dodał do 16 bitowego x86 32 bitowość.
Przez ten manewr, który pozwolił na w miarę szybkie przeniesienie kompilatorów i istniejącego kodu (nawet w assemblerze) na nową 64 bitową architekturę, x86_64 zabrał prawie cały rynek Itanium,  który praktycznie umarł i żyje teraz tylko w highendowych procesorach od Intela, a i sam Intel planuje tę architekturę "umrzeć" w 2021 roku.

Podobne posty^beta
Dla Java'y Apple Silicon M1 to jednak nadal x86 ;-)
W końcu dane z M1, które w Java'ie mówią, że to jest ARM :-)
"CPUInfo" w Java :-)
JNA, czyli w Java'ie też można :-)
Exif jest zły - część 2 :-)