Categories
main mozilla tech

Community Wiki gains OpenID support

I’ve just added OpenID support to Community Wiki. It should make it easier for people to edit the wiki, but its also a step in the direction of Mozilla Community Sites package.

I will write a separate post about MCS, but as many of you know since Fx Summit, I’m working on the set of customized open source web apps that will make setting up a community website much easier. One of the webapps that will be offered is MediaWiki, and one of the features of all the tools will be support for OpenID. Using this on Community Wiki is just a first step 馃檪

Categories
main mozilla tech

Community Wiki

For last two months I have been working on a project that has been in my mind for over 4 years now.

Originally, the idea of what we called a Community Pack appeared during Mozilla Europe Board of Directors discussions between me and Pascal and the first notes drafted by us are located at old MoEu wiki.

Today I’m proud to announce the wiki that one day may become an official community/contribution website for Mozilla. It’s very early in the game, the theme is just something I crafted temporarily, the name has not been decided yet, the structure of the categories may change.

What is there, is an idea with a groundwork already started. The purpose for the website is to help new contributors learn about various activities inside our project and smooth the learning curve.

Beside, the wiki should help people create their own communities, improve community-2-community experience and knowledge exchange. We will try to help smaller communities learn what mature communities know, share the materials we have and address the potential that lies in strong, independent communities existing inside the Mozilla project.

The wiki will not duplicate any material that exists anywhere. It will serve as a kind of roadsign to all the various materials in different places. Wiki.mozilla.org, MDC, SUMO, QMO, SpreadFirefox and others. It’s a Wiki because we want to b

e able to add content in cases where we don’t have where to link to.

The structure of the main page represents the activities that are part of Mozilla, not projects because people who are new to Mozilla don’t know the names of the projects, but will be able to select the activity they’re interested in.

The temporary URL to the front view of the Wiki is http://como.labs.braniecki.net/ but it’ll of course be moved to Mozilla servers pretty soon.

The back end, for editing is http://como-edit.labs.braniecki.net/.

It’s not a perfect solution, but I had no time to work on the skin to make it present all the UI of MediaWiki, especially the theme will be reviewed to m

atch Mozilla sites guidelines.

What now? Well… it’s up to you! First, do you like it? Do you think it may be useful? We want to grow this roadsign, so we want to add urls to your community websites there, to all resources inside Mozilla, and add content in the places where its missing. The one section that requires a lot of work is Community building.

If you are interested in helping, just create an account and start editing! Don’t be afraid of changing thing, we’ll review them.

I will be working on adding content to missing pages, since I’d like all main “category” pages to look at list like Accessibility or Localization. In the next weeks I will be also working on Mozilla customized web tools and Community Website Theme that will help you create new community websites. 馃檪

Categories
main mozilla po polsku tech

TraceMonkey a Tamarin

Wczoraj Mozilla og艂osi艂a prace nad silnikiem TraceMonkey. TM jest modyfikacj膮 aktualnego silnika Gecko – SpiderMonkey, do kt贸rego dodana zosta艂a opracowana przez pracownik贸w Uniwersytetu Kalifornijskiego implementacja algorytmu JIT. Nie jest to mo偶e 偶adna czarna magia, po prostu op贸藕nienie wykonywania skrypt贸w JS (ka偶dy kto pracowa艂 z JS wie, jakie ograniczenia wydajno艣ci JS nak艂ada – nikt raczej nie pokusi艂by si臋 o tworzenie silnik贸w graficznych 3D w JS) jako interpretowanych jest tak du偶a, 偶e okaza艂o si臋, i偶 op艂aca si臋 skompilowa膰 wst臋pnie kawa艂ki kodu JS i w przypadku wyst臋powania powtarzaj膮cych si臋 procedur odpala膰 skompilowane fragementy zamiast interpretowania kodu na bie偶膮co.

Efekty s膮 bardzo wydatne.

Ka偶dy kto 艣ledzi planet臋 Mozilli widzia艂 ju偶 wykresy Brendana, Shavera i Schrepa. Ja wykona艂em ma艂e testy na benchmarku Dromaeo autorstwa niezr贸wnanego Johna Resiga.

Wykona艂em dwa testy – w Fx 3.0.1 i dzisiejszej kompilacji nocnej z w艂膮czonym JIT dla tre艣ci stron.

Wynik dla Fx 3.0.1, Wynik dla Minefield trunk i wynik por贸wnania dw贸ch. Przyspieszy膰 o kolejne 46%? Nie藕le… co? 馃槈

Najlepsz膮 informacj膮 w tym wszystkim jest to, 偶e Brendan twierdzi, 偶e JIT powinien by膰 szybszy w dok艂adnie ka偶dym te艣cie. Je艣li gdzie艣 nie jest, jest to b艂膮d i b臋d膮 to teraz poprawia膰… Ca艂o艣膰 implementacji zaj臋艂a 60 dni i jest to wersja bardzo wst臋pna, najbli偶sze miesi膮ce powinny przynie艣膰 kolejne przyspieszenia wraz z optymalizacj膮 nowych mo偶liwo艣ci.

Co z Tamarinem? Tamarin to znacznie bardziej powa偶ny eksperyment, wymagaj膮cy du偶ego nak艂adu pracy. Ma by膰 on podstaw膮 silnika ActionScript, kt贸ry zast膮pi obecny w platformie Mozilla 2 (i w efekcie w Firefoksie 4).

Obecnie prace nad nim trwaj膮 w osobnym repozytorium na hg.mozilla.org, i zostanie on w艂膮czony do mozilla-central prawdopodobnie po wydaniu Fx3.1. Tamarin ma by膰 oczywi艣cie znowu, znacznie szybszy od TraceMonkey (gdy偶 b臋dzie korzysta艂 z jego dobrodziejstw i dodawa艂 kolejne), b臋dzie te偶 pierwsz膮 implementacj膮 j臋zyka JavaScript 2.0 (kt贸ry dla mnie jest przede wszystkim pokornym wzi臋ciem najwi臋kszych dobrodziejstw Pythona:) ) ale mo偶na go ju偶 dzi艣 przetestowa膰 kompiluj膮c tamarin-central.

Kolcami tej r贸偶y s膮 problemy z debuggerami. JIT sprawia, 偶e ca艂y proces interpretacji przestaje by膰 deterministyczny i nie za bardzo wiadomo jak to obej艣膰. Na razie przy w艂膮czonym Venkmanie, Gecko wy艂膮cza JIT, ale nie jest to optymalne rozwi膮zanie i b臋dzie trzeba poczeka膰, a偶 Gijs wr贸ci z wakacji i podejmie decyzje co dalej z Venkmanem…

Je艣li kto艣 chce w艂膮czy膰 JIT, to mo偶e to zrobi膰 na dw贸ch poziomach – dla stron i dla samego Firefoksa (about:config i szukaj “jit”). W艂膮czenie dla Firefoksa oczywi艣cie znacznie poprawia jego wydajno艣膰 (du偶e cz臋艣ci Fx napisane s膮 w JS), ale jest w tym momencie do艣膰 ryzykowne. Natomiast dla stron jest do艣膰 stabilnie (zanotowa艂em kilka wywale艅 w Gmailu i Facebooku tylko) i z ka偶dym dniem b臋dzie lepiej 馃檪

Docelowo, w ActionMonkey i Mozilla 2, celem Mozilli jest aby jak najwi臋cej kodu by艂o pisanego w JS, a wydajno艣膰 JS by艂a por贸wnywalna z kodem kompilowanym (C++)… Co艣 co wydawa艂o si臋 niemo偶liwe, nie tylko sta艂o si臋 realne, ale jest aktualnie celem programist贸w w projekcie Mozilla. Mam nadziej臋, 偶e si臋 uda 馃檪

Categories
main mozilla po polsku tech

Mozilla naprawia IE – piek艂o zamarza?

Ostatnio pojawi艂y si臋 artyku艂y na temat kilku projekt贸w wewn膮trz Mozilli maj膮cych pom贸c unowocze艣ni膰 Internet Explorera, “No browser left behind” Vlada dodaj膮cy Canvas do IE, czy ScreamingMonkey daj膮cy obs艂ug臋 nowoczesnego JavaScriptu (w za艂o偶eniu JS2.0) w IE.

Dosta艂em kilka maili z pytaniami w tej sprawie, par臋 os贸b podpyta艂o na Jabberze, a na vortalu DobreProgramy komentatorzy sp臋dzaj膮 czas rado艣nie pr贸buj膮c znale藕膰 wyt艂umaczenie dla tego ruchu.

Co ciekawe, w艣r贸d tak wielu teorii ukutych na pr臋dce zabrak艂o tej jednej, rzeczywistej. I wydaje mi si臋 to bardzo symptomatyczne dla wsp贸艂czesnego my艣lenia, 偶e tego typu wyt艂umaczenia rzadko przychodz膮 do g艂owy.

Wyt艂umaczenie to brzmi – celem statutowym Mozilli Foundation jest promocja wyboru i innowacji w Internecie.

Takie trudne? My nie walczymy o zaj臋cie rynku przez nasz膮 przegl膮darke. My walczymy o to, aby Internet sie rozwija艂 i uznali艣my, 偶e optymalnym sposobem do tego jest stworzenie i promocja przegl膮darki, kt贸ra zagwarantuje rozw贸j Internetu w modelu opisanym w Manife艣cie Mozilli (t艂um pl w trakcie prac).

Mozilla jest otwartym projektem i dzia艂a bardziej jak Bazar, czy 艣rodowisko naturalne, ni偶 jak Katedra – zorganizowana i uporz膮dkowana. Wiele rzeczy to inicjatywy oddolne i tak jest w tym przypadku. Ludzie wewn膮trz projektu chc膮 poprawia膰 艣wiat i je艣li Vlad zauwa偶y艂, 偶e przeszkod膮 w adaptacji technologii Canvas jest brak jej wsparcia w IE oraz uda艂o mu si臋 opracowa膰 jak to doda膰, to jest to idealnie wpisane w model jaki chcemy promowa膰 w Internecie.

Tym w艂a艣nie, t膮 r贸偶nic膮 w podej艣ciu, tym, 偶e celem nr.1 ka偶dej firmy s膮 pieni膮dze, a standardy, otwarto艣膰, u偶ytkownicy s膮 艣rodkiem do tego celu, a u nas jest, z definicji fundacji non-profit, odwrotnie wyr贸偶niamy si臋 na rynku i to czyni nasz膮 odpowiedzialno艣膰 ogromn膮, a nasz膮 pozycj臋 i nasze mo偶liwo艣ci unikalne.

Categories
main mozilla tech

Silme moves to hg.mozilla.org

Just a quick note for all stakeholders: silme has been moved to hg.mozilla.org.

Categories
main mozilla tech

Silme progress

First update after public announcement. During last week, Silme received several minor stability patches in trunk and got initial support (patches [1], requests, feedback on API) from several developers including Stefan Plewako from Aviary.pl and Flock projects, Adrian Kalla from Aviary.pl and an intern in Mozilla Corp., and Pike himself 馃檪

Beside of that I spent some time during Firefox Summit on talking with people of Pootle/TranslationToolkit fame to identify potential problems that they faced. It was extremely supportive for me and gave my major take away is that if I want to reach my goal of having one, common abstraction layer for l10n objects I have to merge two very different concepts – single locale files (like DTD, properties, ini) and multi-locale files (XLIFF, GetText, tc).

Multilocale branch has been ignited to address this. I already did several tests and it seems that I will be able to support both models in one API without making both feel like hacks.

Pike raised another concern, that I tried to keep for later which is a concept of entity/l10nObject processing. Initially I assumed that it’s a minor topic, and on this level of abstraction I assumed that leaving the entity values unprocessed is OK for now. Unfortunately, especially with L20n being the next Big Thing for Silme, entity processing becomes very important and has to become a legimate element of the library skeleton.

I started early hacks of l20n.py format parser leaving my brain in free conceptual thinking mode and waiting for Pike’s time to talk about grammar inconsistencies.

Last big thing to come is a soon to happen switch from svn repo on my server, to shiny new hg.mozilla.org. This requires me to spend a few hours on svn-to-hg migration tools, but should help with later branching and support easier collaboration between many developers.

Current roadmap is pretty dense for stage3, and may be latter splitted, but does not currently involve work on end-user oriented apps like a webtool. Once I have this two major restructurizations ready (multilocale/pre-processing), I’ll get back to providing proof-of-concept tools. We’re of course looking for more developers so let me know if you’re interested 馃檪