пропозиції роботи
Wypowiedzi
-
Zadałeś pytanie z cyklu:
"Czym sprawdzić czy wszystko ok z moim samochodem? Moje typy to sprawdzić silnik, zawieszenie".
Nie oczekuj, że ktoś na podstawie tego napisze elaborat o technikach, narzędziach, wnioskowaniu itd. Nie bez przyczyny takie pytania są zbanowane na StackOverflow. -
"JavaScript", nie "Javascript" i "rzeczywistych", nie "żeczywistych".
(ok, doczytałem, że to zamierzone, sorry ;))Ten post został edytowany przez Autora dnia 10.09.13 o godzinie 08:43 -
/\s/.test('\n')
true
/\S/.test('\n')
false
/./.test('\n')
false
-
Rok temu przerzuciliśmy się w CKEditorze na JSDuck (z JSDoca bodajże). Był to krok milowy bo z czegoś tak nieprzyjemnego jak to http://docs.cksource.com/ckeditor_api/ przeszliśmy na http://docs.ckeditor.com
Poza tym, że dokumentacja wygląda dobrze, to JSDuck ma jeszcze wiele innych ficzerów jak:
* Fakt, że to SPA.
* Taby.
* Wyszukiwarka (dzięki temu jest niesamowicie przydatna w codziennej pracy).
* Możliwość dokumentacji eventów.
* Kolorowanie składni w samplach.
* Bezproblemowe dokumentowanie właściwości obiektów które są argumentami, czy argumentów jakiegoś callbacka. Generalnie - bezproblemowe dokumentowanie JS-a, a zapewne jeszcze lepsze aplikacji napisanych z wykorzystaniem EXT-a.
* Możliwość przejścia z definicji do źródła (do odpowiedniej linii w kodzie).
* Zintegrowany guide'y (http://docs.ckeditor.com/#!/guide).
* Łatwość rozszerzania.
* Fakt, że jest aktywnie rozwijany i szybko łatane są błędy.
Dwa minusy jakie przychodzą mi do głowy to:
* Dokumentacja takiego projektu jak CKEditor trochę waży, więc chwilę się ładuje.
* Zdaje się, że ciągle mamy jakiś problem z indeksowaniem tego przez Google, ale nie mieliśmy czasu jeszcze sprawdzić po której stronie on leży i korzystamy z lekko przestarzałej wersji JSDucka. -
Maciej G.:
W moim przypadku dużo wniósł do nauki JS ten kurs. Pokazuje jak zastosować wiedzę książkową w praktyce.
Ten kurs wygląda przeraźliwie. Jakbym się cofnął 10 lat. Niepoprawny kod, złe praktyki... Gorąco odradzam, jeśli ktoś nie chce stracić 50zł i kilku godzin życia. -
-
Zaciekawiło mnie o ile droższe może być operowanie na datasetach w DOM-ie w porównaniu z native JS. Co prawda nie wiem jak robi to AngularJS, ale stworzyłem taki prosty test, którego wynik w zasadzie mnie zdziwił. Spodziewałem się bardziej zbliżonego rezultatu, a także wolniejszego getAttribute/setAttribute od operowania na dataset.
http://jsperf.com/dom-vs-js-data
EDIT: dodałem jeszcze w sumie bardziej sensowny case z dostępem do pól obiektu, bo ten z tablicą dostaje zbyt dużego boosta pewnie dzięki swojej prostocie i już wyniki są bardziej zbliżone. Przy czym ciężko powiedzieć czy nie zaburzam wyników tworząc klucze, ale już mi się nie chce kombinować z bardziej sensownymi case'ami.Piotr Koszuliński edytował(a) ten post dnia 12.04.13 o godzinie 14:37 -
Łukasz Nowacki:
Krzysztofowi chyba chodziło o stawki i outsourcing na wschód?
To już nadinterpretacja ;). Zaś moja interpretacja jest zdecydowanie bardziej trafna uwzględniając poprzednie wypowiedzi w tym temacie i ";/" dodane na końcu :P. -
Krzysztof F.:
I tak to my jesteśmy Indiami europy :/
E tam. Jesteśmy tam gdzie nasza gospodarka - ani na szarym końcu, ani w topie. Ale kto spotkał się z "pracownikami" z Indii ten nigdy nie napisze o nas, że jesteśmy "Indiami Europy". Na prawdę nie mamy sobie czego zarzucić - nawet jeśli zawęzimy kontekst do Europy. -
Łukasz Lityński:
a co myślicie o asm.js, który pozwala(albo ma pozwalać? nie wiem na jakim poziomie zaawansowania jest ta technologia) kompilować C++ do JavaScript.
http://kripken.github.com/mloc_emscripten_talk/#/19
podobno ma to być super szybkie, szybsze podobno od zwykłego JS, bo jakieś super optymalizacje mają być porobione.
Nie śledzę newsów o asm.js, więc nie do końca wiem jak teraz stoi, ale sam pomysł uważam za świetny. Zamiast robić coś kompletnie od nowa, zróbmy coś w obrębie istniejącej technologii, co pozwoli nam użyć już istniejących rozwiązań.
Nie wiem czy kojarzysz Emscripten? Pozwala przekompilować LLVM bitcode (jeśli dobrze rozumiem, pośrednią postać wygenerowaną z kodu C/C++) do JS. W ten sposób powstały JS-owe klony wielu znanych natywnych programów (https://github.com/kripken/emscripten/wiki#demos).
Najlepsze w Emscripten jest to, że kompiluje kod do prostego C-like JavaScriptu, który nawet bez manualnej optymalizacji jest całkiem szybki. Dzięki niemu zyskujemy możliwość przeportowania natywnych narzędzi do JS - to już samo z siebie brzmi niesamowicie.
Ale teraz pójdźmy krok dalej - pomóżmy przeglądarce lepiej zrozumieć, a więc zoptymalizować kod wygenerowany przez Emscripten. W tym celu potrzebujemy dokładnie określić ramy wycinka JS-a, który jest używany przez Emscripten. Tym dokładnie jest asm.js - specyfikacją wycinka JS. Wstępne benchmarki wykazały, że asm.js (w FF) jest jedynie 2x wolniejszy od programów skompilowanych przy pomocy clang.
Tak więc asm.js ma wiele zalet:
* już jest zaimplementowany w wielu przeglądarkach (bodajże tych z implementacją typed arrays?),
* pozwala użyć w środowisku webowym już napisany i sprawdzony kod,
* jest akceptowalnie szybki jeśli przeglądarka go nie wspiera (to znaczy implementuje minimum wymaganego JS-a, ale nie optymalizuje asm.js),
* jest super szybki (jak na webowe standardy) jeśli przeglądarka go wspiera. -
Piotr L.:
Piotr Koszuliński:
Wśród programistów ta moda zapewne nigdy nie przeminie (też zdarza mi się w ten sposób grzeszyć). Co ciekawe bardzo często tego typu podejście daje gorszy rezultat niż istniejące już rozwiązanie, mimo założenia sobie bardzo szczytnych celów. Interesującym przykładem może być CoffeeScript, który choć starał się poprawić język posiadający wiele wad, wprowadził tyle nowych, że te poprawione blakną.
Bez wynajdywania koła na nowo człowiek by nic nie odkrył, nie powstała by setka frameworków do PHP czy dystrybucji Linuxa i wszyscy używalibyśmy systemu spod znaku wielkiego błękitu (ktoś pamięta co to jest OS/2 Warp?). Ciągłe próbowanie nowych rozwiązań jest podstawą ewolucji, także w programowaniu - kto siedzi ciągle tylko przy ulubionym (w swoim mniemaniu najlepszym) narzędziu ten się nie rozwija. Po co miałyby powstawać smart pointery w C++ gdyby nie było Javy?
Dlaczego programista Perla napisał parsera do PHP-a? Czy to źle że powstał C#? Co by było z Javą gdyby go nie było? itd...
Nie krytykuję postawy "zróbmy to od nowa, ale lepiej" jako takiej. Bez krzyżówek i mutacji ewolucja by nie istniała. W zasadzie nie należy mojego poprzedniego komentarza traktować dosłownie, bo miał być przede wszystkim humorystyczny ;P.
Jeśli jednak już jesteśmy przy temacie, to mówiąc o komercyjnych (bądź zbliżonych wymaganiami) projektach (własne "zabawki" rządzą się innymi prawami) jestem jak najbardziej za próbowaniem swoich własnych sił jeśli:
* istniejące rozwiązania z jakiegoś powodu nam nie pasują (problem z integracją, słaba jakość, nie w pełni spełnione wymagania, licencja, wsparcie itp.),
* stać nas na to - to znaczy zysk z lepszego końcowego rezultatu, będzie większy niż strata czasu.
Jak to wszystko ma się do CoffeScriptu? Raczej nijak - AFAIK CS nie spełnia kryterium "komercyjności". Nie mogę zarzucić komuś, że spróbował zrobić coś od nowa, lepiej. Tak jak pisałem we wcześniejszych postach - CS wniósł swoje do prac nas ES6 i chwała mu za to. To genialny PoC, ale... no właśnie - powinien pozostać ciekawostką, do zastosowań w innych ciekawostkach. Za żadne skarby nie powinien być pchany do czegoś komercyjnego, bądź z założenia mogącego być wykorzystanym w tego typu projektach (np. otwarte biblioteki jak Spine). Z tym, że winę za to ponoszą ci którzy dokonywali wyboru, a nie autorzy CS. -
O ile "czysty JS" nie oznacza JS bez DOM-a, to...
CKEditor używa takiego tricku że wrzuca to w jakiś element (np. body) i pobiera z powrotem. Przeglądarka poprawia wiele rzeczy sama.
var fixbin = document.createElement( 'body' );
fixBin.innerHTML = input;
var output = fixBin.innerHTML;
Niestety:
* Różne przeglądarki potrafią przy tym popsuć różne rzeczy. Np. pozmieniać adresy z relatywnych na pełne. Tak więc jeśli nie chcesz naprawiać takich rzeczy, to musiałbyś je wcześniej zabezpieczyć (co CKEditor też robi).
* Nie wszystko przeglądarki naprawią i nie będziesz również miał jednolitego wyniku. Np. HTML z IE będzie czasem jeszcze gorszy :D. Dlatego CKE następnie wszystko parsuje do drzewa obiektów i następnie z powrotem serializuje.
I tak naprawdę jeśli bym szukał rozwiązania to w postaci parsera HTML + writera (choć tego można łatwo samemu napisać). Jeśli parser jest porządny, to nie musisz używać tego tricku z przepuszczaniem przez fixBin. CKE go stosuje by później móc użyć parsera opartego na Regepx, który w tym wypadku daje dobre rezultaty i jest optymalny.Piotr Koszuliński edytował(a) ten post dnia 20.03.13 o godzinie 16:47 -
Marcin Drwięga:
Czy mi się wydaje, czy większość poleca tu pisanie aplikacji w "gołym" języku?
Nie. Raczej nikt tego nie poleca. Domyślam się, że wszyscy korzystają z różnego rodzaju bibliotek wspomagających pisanie aplikacji. Bibliotek JS-owych oczywiście.
Myślałem, że "Era odkrywania koła na nowo" minęła jakieś 15 la temu ;)
Wśród programistów ta moda zapewne nigdy nie przeminie (też zdarza mi się w ten sposób grzeszyć). Co ciekawe bardzo często tego typu podejście daje gorszy rezultat niż istniejące już rozwiązanie, mimo założenia sobie bardzo szczytnych celów. Interesującym przykładem może być CoffeeScript, który choć starał się poprawić język posiadający wiele wad, wprowadził tyle nowych, że te poprawione blakną. -
Jeśli chodzi o debuggowanie CS, to sam nie mam w tej kwestii doświadczenia, bo omijam ten język szerokim łukiem. Podpytywałem jednak znajomych i twierdzą, że dzięki source mapom nie ma z tym większego problemu (BTW Google Closure Compiler, czy Uglify JS też potrafią produkować source mapy). Czyli w teorii nie jest tak źle. Jednakże padła w tym temacie bardzo ciekawa uwaga - co z przeglądarkami, w których JS/DOM działa inaczej, a które nie mają wsparcia dla SM? To w nich najczęściej trzeba coś debuggować, oczywiście o ile musimy je wspierać.
W kwestii CS smuci mnie jednak inna sprawa. Rozmywa nam jednorodne środowisko o które tak walczymy. Z jednej strony wszyscy chcemy, żeby przeglądarki implementowały wspólne, jednolite standard, bo to czyni życie znacznie prostym - piszemy jedną wersję kodu, piszemy szybciej i mniej musimy wiedzieć o dziwactwach. CS i inne podobne propozycje rozmywają nam ten piękny świat. Pojawia się nowy byt, który trzeba znać, którego rozwój trzeba śledzić i który może spowodować, że trudniej będzie nam skompletować sprawny zespół. I nie jest tak, że ode mnie, czy mojego szefa zależy, czy użyjemy CS. Niestety wiele ciekawych bibliotek, które powstały w ostatnich czasach zostało stworzonych w CS. Sam miałem już z tym problem, że musiałem próbować znaleźć coś w kodzie napisanym w CS, a jego składnia nie jest dla mnie zbyt czytelna.
Tak więc CS robi społeczności podobną krzywdę jaką od wielu lat robi jQuery. Ciekawe rozwiązania, które powinny mieć jak najmniej zależności, często mają nieakceptowalne wymagania.
Żeby jednak nie być jednostronnym - cieszy mnie wpływ CS na prace nad ES6. Jest to dobry poligon doświadczalny, dobrze by jednak było, gdyby pozostał "doświadczalny" :). -
Łukasz Lityński:
- bardzo podobna notacja tablic i obiektów (chociaż w Pythonie nazywa się to listami i słownikami. Ale jakby się nad tym zastanowić to kompilator Pythona mógłby spokojnie odczytać poprawnie skonstruowanego JSONa:
Nawet JS nie da rady sparsować poprawnie sformatowanego JSON-a. Nikt tutaj oczywiście nie stwierdził wprost, że JSON jest podzbiorem JS, ale wiedząc, że wiele osób tak myśli pozwalam sobie wrzucić tego oto linka: http://timelessrepo.com/json-isnt-a-javascript-subset -
Wkleiłeś tylko mały wycinek (brakuje np. pokazania jak inicjalizujesz CKEditor), ale zapewne to Ci pomoże.
Dodaj na początku funkcji createArticle() kod:
CKEDITOR.instances.tfArticle.updateElement();
To spowoduje skopiowanie zawartości edytora do textarea (bo to nie jest ten sam element).
Albo pobierz wartość edytora wprost. Czyli zamiast:
var tfArticleText = document.getElementById("tfArticle").value;
użyj:
var tfArticleText = CKEDITOR.instances.tfArticle.getData();
Piotr Koszuliński edytował(a) ten post dnia 05.02.13 o godzinie 15:06 -
Mirosław Ratman:
To juz tyle razy bylo tu walkowane ;) - ckeditor ( hehe Piotr, ale Wam ruch nakręcam :) )
Heh :) W tym wypadku akurat nie polecę CKEditora (ani nawet TinyMCE :P). Zdaje się, że Konrad szuka edytora dokumentów, nie (fragmentów) stron. To inna bajka i edytory oparte na conteneditable się do tego nie nadają, bo takie sprawy jak podział na strony, przepływanie tekstu i obiektów, zachowanie rozmiarów w druku są w nich nie do uzyskania (na sensownym poziomie).
Niestety, poza edytorami opartymi o contenteditable znam tylko Google Docs i EtherPad (http://etherpad.org/). Ale pierwszego chyba nie da się sensownie zintegrować, a drugi jest w zasadzie zbudowany jako proste narzędzie do real time collaboration.Piotr Koszuliński edytował(a) ten post dnia 01.02.13 o godzinie 11:43 -
Mirosław Ratman:
CKEditor
Dokładnie. Jeśli nie chcesz spędzić kilku najbliższych lat na próbie stworzenia używalnego edytora, to użyj jednego z istniejących, jak np. CKEditor. -
Mirosław R.:
http://cksource.com/ckeditor
Raczej http://ckeditor.com ;) Nie trzeba od razu kupować :P. -
Zaraz, zaraz. Ktoś twierdzi, że JS nie jest obiektowy? :D Hahahaha. To się uśmiałem. Turlam się po ziemi. Dlatego, Sylwester, tak jak pisałem - najpierw poznaj JS - później zacznij narzekać, bo się po prostu ośmieszasz ;).Piotr Koszuliński edytował(a) ten post dnia 27.11.12 o godzinie 11:54
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
