недавно вышла IDE WebStorm специально для веб-разработчиков. Я скачал её на попробовать, впечатлился, и даже подумал купить её. Но как же обойтись без небольшого исследования перед приобретением важного рабочего инструмента? : )
последний раз я сравнивал IDE пару лет назад, и не нашёл ничего достаточно хорошего. Все они приблизительно одинаково не подходили под мои требования. В итоге я остановился на Komodo Edit, который хотя бы тормозит меньше, чем остальные. Но порой за два года многое меняется. Итак, вот мои претенденты.
Eclipse — классная среда. В ней очень умно и удобно сделано почти всё. Собственно, именно её я использовал, когда работал преимущественно не с js. Однако поддержка яваскрипта в ней всегда хромала. Под эклипс есть несколько плагинов, поддерживающих яваскрипт, и все они почти блокнотного уровня. JSEclipse выкуплен и убит Адобом. Spket ничем особенным себя не проявляет. WebTools, хотя и сменил версию с 1.5 на 3, по-прежнему примитивен.
Aptana я пущу отдельным абзацем, хотя это тоже перелицованный эклипс. Хвалят её, конечно, и даже тормозить она перестала (странно было: эклипс не тормозит, а аптана еле шевелится). Но в плане яваскрипта ушла недалеко.
NetBeans оказался вполне прикольным. Местами лучше эклипса, местами похуже, да и страшноват. Но тоже обрабатывает каждый файл как вещь в себе.
Visual Studio я не рассматривал по понятным причинам ; )
в чём же обломались все перечисленные IDE? В примитиве. Go to definition работает, только если функция определена в этом же файле. Это смешно для любого хоть сколько-то крупного проекта. Даже Komodo иногда справлялся с этой задачей.
в общем, пока что я попробую остановиться на WebStorm, благо демка у него на 45 дней.
да, на всякий случай скажу, что между набором простых утилит и gui я выбираю gui
я люблю консоль для тех задач, которые целиком помещаются у меня в голове. Если же я чего-то не знаю, и требуется исследовать, например, содержимое каталога, то файловый менеджер намного упрощает жизнь. И в программировании крайне редко случается так, что я целиком осознаю то, что делаю. Такое бывает, только если пишется минимального размера скриптик — это действительно можно сделать и в подручном блокноте
но программирование серьёзных вещей целиком построено на абстракциях. Ты абстрагируешься, отвлекаешься от частностей, чтобы сосредоточиться на более высоком уровне сложности. И в силу сложности задачи получается развесистое дерево, которое целиком загрузить в голову невозможно. Поэтому зачастую становишься исследователем чужого, а порой и своего кода. А для исследования как раз лучше всего gui.
кстати, мой любимчик — highlight selected. Поставил курсор на слово, и оно подсветилось во всём тексте. Для этого нужно нажать ноль клавиш.
По большей части эта статья — изложение сути статьи "Brewer's CAP Theorem" Джулиана Брауна. В оригинале много полезных ссылок и интересных примеров, поэтому если позволяет время и знание языка, почитайте его. А здесь у меня просто самая суть, покороче и по-русски.
В 2000 году Эрик Брюер выдвинул гипотезу, касающуюся ключевых свойств распределённых систем, которую затем доказали в MIT, и с тех пор она называется теоремой Брюера или теоремой CAP (Consistency-Availability-Partition tolerance). Вольная формулировка:
В распределённой системе невозможно обеспечить одновременное выполнение всех трёх условий: корректности, доступности, устойчивости к сбоям узлов.
Что это за свойства.
Говорит о том, что система всегда выдаёт только логически непротиворечивые ответы. То есть не бывает такого, что вы добавили в корзину товар, а после рефреша страницы его там не видите.
Означает, что сервис отвечает на запросы, а не выдаёт ошибки о том, что он недоступен.
Означает, что распределённая по кластеру система продолжает работать корректно при недоступности нескольких серверов кластера (кроме случая, когда упали все сервера, конечно).
Для лучшего осознания, вот три соответствующих примера того, что могут представлять собой системы без одного из этих свойств:
Шардированная СУБД, в которой данные лежат только на собственных серверах. В ней не может произойти неконсистентностей, и она доступна, если пользователь пишет новые данные или читает данные с доступного шарда. Однако она вообще не отдаёт часть данных, лежащих на недоступных шардах, а следовательно банально нецелая.
Система с несколькими мастер-базами, которые обновляются синхронно. Она всегда корректна, потому что транзакция отрабатывает, только если изменения удалось распространить по всем серверам БД. Она продолжает корректно работать по крайней мере на чтение, если один из серверов падает. А вот попытки записи будут обрываться или сильно задерживаться, пока система не убедится в своей консистентности.
Система с несколькими серверами, каждый из которых может принимать данные, но не обязуется в тот же момент распространять их по всему кластеру. Система переживает падения части серверов, но когда они входят в строй, они будут выдавать пользователям старые данные.
Важность того, что невозможность обеспечить все три свойства сразу, доказана математически, избавляет нас (тупых инженеро́в :-) ) от тщетных попыток создать некую идеальную систему, которая никогда-никогда не ломается. Вместо этого мы теперь можем делать привычный нам инженерный выбор двух из трёх.
Как в известном предложении клиенту: "быстро, дёшево, качественно — выбирайте любые два".
Причём, как в большинстве инженерных ситуаций, этот выбор не стоит как "всё или ничего". Система может располагаться где угодно в пределах этого воображаемого треугольника, быть "более" консистентной, "менее" доступной и "слегка" нецелой. В анти-идеале можно написать систему, у которой будет плохо со всеми тремя компонентами. Уверен, вы с такими встречались :-).
Одно из интересных практических следствий этой теоремы в том, что в последнее время многие бизнесы решили для себя, что совсем не обязательно упираться в принципы дизайна ACID, который ставит во главу угла Consistency, жертвуя двумя другими свойствами. Теперь у нас есть такая альтернатива, как BASE (известная также как "eventual consistency"), которую например очень любят и используют в Amazon. Там во главе угла стоит Availability.
А ещё один дядька — Гай Пардон — вообще предлагает инженерное решение, которое обходит проблему CAP. Правда, он немного читерствует (с математикой трудно спорить), говоря, что хоть и нельзя обеспечить все три свойства одновременно, можно построить систему так, чтобы она достигала желаемого постепенно.
Rick Waldron has been delving into Chrome and Chromium to find some nice updates.
First, he uncovers new support for the EventSource API that allows for simple server push of DOM events as shown in this simple client and server pairing:
Then, he finds out that the Web Worker API now supports complex messages, so you can postMessage
more than Strings. Send over objects and Arrays with ease:
obj.isArray = [ 1,2,3,4,5 ];
obj.isString = 'Foo bar baz',
obj.resultOf = (function () {
return 'returned from self executing function';
})();
worker.postMessage(obj);
// TEST STRING ARG
worker.postMessage('Hello Worker Process');
// TEST ARRAY ARG
worker.postMessage([ 1, 2, 3, 4 ]);
// TEST BOOLEAN ARG
worker.postMessage(false);
OpenCart CSRF Vulnerability. Avoid OpenCart—it’s vulnerable to CSRF, but the maintainer has no intention of fixing it as “there is no way that I’m responsible for a client being stupid enough to click links in emails”.
Busting frame busting: a study of clickjacking vulnerabilities at popular sites (via). Fascinating and highly readable security paper from the Stanford Web Security Research group. Clickjacking can be mitigated using framebusting techniques, but it turns out that almost all of those techniques can be broken in various ways. Fun examples include double-nesting iframes so that the framebusting script overwrites the top-level frame rather than the whole window, and a devious attack against the IE and Chrome XSS filters which tricks them in to deleting the framebusting JavaScript by reflecting portions of it in the framed page’s URL. The authors suggest a new framebusting snippet that should be more effective, but sadly it relies on blanking out the whole page in CSS and making it visible again in JavaScript, making it inaccessible to browsers with JavaScript disabled.
Django 1.2 release notes (via). Released today, this is a terrific upgrade. Multiple database connections, model validation, improved CSRF protection, a messages framework, the new smart if template tag and lots, lots more. I’ve been using the 1.2 betas for a major new project over the past few months and it’s been smooth sailing all the way.
This feature has landed in Mozilla Central (trunk) and only available with a Firefox Nightly Build for the time being.
XMLHttpRequest Level 2 (editor’s draft) adds support for the new FormData interface. FormData objects provide a way to easily construct a set of key/value pairs representing form fields and their values, which can then be easily sent using the XMLHttpRequest send() method in “multipart/form-data” format.
When you want to send complex data to a server from a web page (files, non-ASCII content), you must use the multipart/form-data
content type. To set the content type in a <form>
, you write:
<form method="post" enctype="multipart/form-data" action="http://foo.bar/upload.php"> <input type="file" name="media"/> <input name="nickname"/> <input name="website"/> <input type="submit" value="upload"/> </form>
This is what you usually do to upload a file.
Starting with Firefox 3.6, you can manipulate files with JavaScript (see File API), and maybe you want to send files using XMLHttpRequest. But if, for example, you want to reproduce this form, it’s really hard because you’ll have to create the multipart/form-data
content yourself in JavaScript (see, for example, this code I wrote a while ago implementing a multipart/form-data
: ugly and slow).
This is where FormData is useful: to reproduce the <form>
submission mechanism in JavaScript
The FormData object lets you compile a set of key/value pairs to send using XMLHttpRequest. This object has only one method:
append(key, value);
where key
is the name of your value, and where value
can be a string or a file.
You can create a FormData object, append values and then send it through XMLHttpRequest. If you want to simulate the previous form, you write:
// aFile could be from an input type="file" or from a Dragged'n Dropped file var formdata = new FormData(); formdata.append("nickname", "Foooobar"); formdata.append("website", "http://hacks.mozilla.org"); formdata.append("media", aFile); var xhr = new XMLHttpRequest(); xhr.open("POST", "http://foo.bar/upload.php"); xhr.send(formdata);
<form>
elementFirefox extends the HTML form element slightly, adding a getFormData()
method that lets you fetch a form’s data as a FormData object. This is not yet part of the HTML standard, but is expected to be added to the specification at some point in the future (although possibly with a different name):
var formElement = document.getElementById("myFormElement"); var xhr = new XMLHttpRequest(); xhr.open("POST", "submitform.php"); xhr.send(formElement.getFormData());
You can also add data to the FormData object between retrieving it from a form and sending it, like this:
var formElement = document.getElementById("myFormElement"); formData = formElement.getFormData(); formData.append("serialnumber", serialNumber++); xhr.send(formData);
This lets you augment the form’s data before sending it along, to include additional information that’s not necessarily user editable on the form.
Развенчал «Мифы о Перле» — для перловиков и, в особенности, представителей других культур: http://sites.google.com/site... #devconf #perl
|
What’s different about the new Google Docs? - http://googledocs.blogspot.com/2010...
|
After almost three years working on various discovery proposals, I’m finally starting to see the light at the end of the tunnel. While slow, good progress is being made and the drafts are reaching maturity and gaining popularity.
Just a quick update on the status of the various parts of the discovery stack (aka The Hammer Stack):
If you care about any of this, it is critical to review the host-meta and LRDD documents. They are both short and include plenty of detailed examples. Feedback would be greatly appreciated on the Apps Discuss list.
A Brief, Incomplete, and Mostly Wrong History of Programming Languages - http://james-iry.blogspot.com/2009...
|
Shared by artyТак, например, пользователи могут проследовать по адресу موقع.وزارة-الأتصالات.مصر, который состоит из доменов первого и второго уровня на арабском языке. Всего на сегодняший день запущено три нелатинских домена верхнего уровня: السعودية. ("Al-Saudiah", для Саудовской Аравии), امارات. ("Emarat", для ОАЭ) и مصر. ("Misr", для Египта). Согласно правилам арабского языка, все они читаются справа налево.
что, россия не первая с национальными доменами?
What if you could make the IP packet handling code look almost identical to the RFC 791 diagram which defines IP? This is real code in their system. That's right; the ASCII art diagram is the code. - http://www.moserware.com/2008...
|