love5an: (R)
Давно ничего не писал. Набросаю тут важные вещи, которые за долгие годы работы в этом вашем айти, четко сформировались в голове. Чтобы самому не забыть, в том числе.

Итак, "сегодня мы многое поняли":

1. Никогда не доверяйте хайпам, они приходят и уходят, а разброд и шатание после них чинить вам же.

2. Если у вас действительно важный проект и/или ограниченный бюджет, никогда не нанимайте дешевых разработчиков и/или т.н. джуниоров и мидлов уровня среднестатистического аутсорса. Это будет провал проекта, или же большие убытки. Опытные разработчики с большим стажем, хорошей эрудицией и солидным послужным списком - всегда дешевле, несмотря на необходимость платить высокую заработную плату.

3. Всегда, в любом проекте, необходимо очень хорошо, досконально, знать предметную область. При любой возможности интересуйтесь ей, например за стаканом пива с заказчиком, если такая возможность есть; если нет - самостоятельно изучайте.

4. При любой возможности, уточняйте любую мелочь, неточность и неясность в техзадании. Любую.

5. Не прикасайтесь к проектам без техзадания и четкого видения проекта. Никогда. Сами же окажетесь виноваты в провале.

6. Выбирайте работодателей. Не соглашайтесь на первую попавшуюся работу только потому, что у вас финансовые проблемы. Всегда интересуйтесь, на кого вы на самом деле работаете, в частности, интересуйтесь статистикой успешных проектов заказчика, а также мнением предыдущих работников/контракторов. Это очень важно.

7. Скрам не работает. Как и вообще, весь этот Agile. Не стоит тратить время на все эти митинги и прочий бред, если вы, конечно, не скрам-евангелист, и не зарабатываете этим бабки(позор на весь ваш род, в таком случае).

8. При первых же проблемах с деньгами, бесцеремонно уходите, если, конечно же, это не ваш личный стартап(доля в проекте). Никогда не слушайте пламенных речей и обещаний, особенно в случае с заказчиками и работодателями из бСССР.

9. За каждую задачу и группу задач, должен быть кто-то ответственнен. Сделайте так чтобы, каждый разработчик был за что-то ответственнен. Нет личной ответственности - провал проекта гарантирован.

10. Все сроки проваливаются. Умножайте оценки не в 2 раза, а в 5-10.

11. По часам оценивать задачи смысла нет. Только по дням, а иногда, по неделям.

12. Программист не может продуктивно работать больше 4-5 часов в день. В принципе.

13. У NoSQL очень ограниченная область применения. Применим он только там, где данные можно потерять.

14. Микросервисы не работают. Просто не работают. "Не пытайтесь повторить это дома". Зато, отлично работает грамотная модульность в сервисах. Грамотно продуманные интерфейсы и DI, если у вас ООП.

15. Под REST все понимают не то, что нужно. Впрочем, это не так плохо, потому как "настоящий" REST мало где применим.

16. Никогда не переизобретайте аутентификацию, авторизацию, и криптографию, если для вашей платформы это есть. Никогда.

17. Никогда не допускайте веб-разработчиков до работы с СУБД. В принципе, никогда не допускайте до СУБД разработчиков на следующих платформах и языках: Ruby, Python, ASP.NET, PHP, Node.js, и подобных им. Никогда. Пусть используют ваше API.

18. Всегда делайте stateless API. Да, с вебсокетами и прочим дуплексом, это тоже возможно, правда.

19. Всегда заранее планируйте возможность горизонтального масштабирования серверной части. Заранее выберите Message Broker, например RabbitMq. Заранее подумайте об общем хранилище сессий веб-приложений, например о Redis, и так далее. Вообще, всегда планируйте это, если пишете не лендинг.

20. Одна из главных проблем разработки программного обеспечения - инвалидация кеша. Не кешируйте там, где огромная польза кеширования не очевидна, потом пожалеете. Лучше воткните под СУБД коробку побольше.

21. Не держите систему на собственных серверах, особенно в РФ. Используйте облачные сервисы, в частности, AWS. Не жалейте на них денег.

22. В конечном счете, проблемы с производительностью всегда идут от I/O и СУБД.

23. UI это всегда боль. Терпите, или уходите в Backend.

24. Отдельный DBA, с возможностью давать линейкой по рукам, в том числе и вам самим - это очень хорошо.

25. Отдельный DevOps - тоже.

26. Не так страшна винда, как её малюют. Во многих отношениях - очень даже хороша.

27. Мало кто знает, как правильно использовать индексы РСУБД. Но еще меньше кто знает, насколько сложно их использовать правильно, и часто ли имеет смысл это делать.

28. Не используйте ORM ни для чего, кроме совсем примитивных запросов. ORM не работают.

29. Генераторы и конструкторы UI - отличная вещь. Если вам наплевать на внешний вид.

30. Пишите документацию по ходу разработки. Будет полезна в том числе вам самим. Комменты в коде не пишите, их никто не читает.

31. Тестировщики, как отдельная профессия, совершенно не нужны, это маркетинговый ход аутсорс-бизнеса. Тестировщиками должны выступать проектировщики, люди со знанием предметной области, и будущие пользователи.

32. Наличие большого коммьюнити и большого количества opensource библиотек у платформы/языка сильно переоценено. Не касаясь качества, как коммьюнити, так и библиотек, возможности кастомизации и прикручивания библиотек под свою задачу, а это всегда проблемные вопросы, скажу что большую часть кода вам все-равно придется писать самому, на выбранной платформе и языке программирования, а здесь - возможности и выразительность этой платформы и языка - играют огромную роль. Если касаться вопросов поиска сотрудников, то поверьте, любого грамотного человека можно обучить любой платформе, хоть тому же Лиспу или Хаскелю. А с неграмотными работать просто не стоит, как я выше сказал. И, да, я по-прежнему считаю, что Лисп это круто.

33. Вообще, фундаментальные принципы и идеи - знать и понимать гораздо важнее, чем какие-то мелочи и конкретику. Выучите лисп, в конце-концов!

34. Знать английский язык очень важно. Постоянно совершенствуйте уровень владения английским, как устным, так и письменным. Смотрите обучающие ролики на ютубе, и кино на английском, в конце концов. Американский английский - важнее, чем другие разновидности. По возможности старайтесь избавиться от акцента.

35. Не мучайте соискателей на собеседовании. Лучшие два вопроса это "работать будешь?" и "сколько хочешь денег?". Впрочем, всегда интересуйтесь их бэкграундом и взглядами на жизнь и IT.

36. Нет, математика, за исключением арифметики, вам в IT не пригодится. Алгоритмику и прочий CS я за математику не считаю, но впрочем, и оно вам мало где пригодится.

37. Пить вредно.

-- Ваш Капитан Очевидность.
love5an: (R)
Так получилось, что по ряду причин я снова ищу работу, причем достаточно срочно.

Готов как на full-time, так и на part-time или разовые таски.

CV по ссылке: https://dl.dropboxusercontent.com/u/5521262/CV2015.pdf

Если вкратце - умею достаточно много всего, но основные скиллы находятся в области Windows(это как .NET, так и нейтив, на C++ и не только), Web-разработки (ASP.NET MVC, Silverlight, разнообразный client-side веб, вроде AngularJS, и т.д. и т.п.), Erlang, и конечно Lisp.

Предложения лучше всего слать на lovesan.ru at gmail.com

Тег lisp для попадания в рассылки.
love5an: (R)
В Петербурге, 28го ноября, пройдет очередной IT Global Meetup.
http://piter-united.ru/itgm/itgm.html

В числе участников - лисперы, во главе со мной и Мишей Глуховым([livejournal.com profile] rigidus).

Мы двое, соотвественно, точно будем выступать и представим доклады.

Хотелось бы узнать, желает ли кто-нибудь еще вместе с нами подготовить какой-либо доклад на тему лиспа? Уже требуется подтвердить программу, так что дайте знать как можно скорее.
love5an: (R)
Такое написал: https://github.com/Lovesan/SimpleAudioPlayer

Вобщем, библиотечка, основанная на DirectShow, которая позволяет проигрывать аудио. В т.ч. не только из файлов, а скажем и по http.

Библиотечка имеет COM-интерфейс, соответственно, ее можно использовать из разных языков - включены, в частности, CLI-интерфейс на чистом Си, интерфейсы для .NET и для Common Lisp.


(defvar *player* (make-instance 'cl-sap:simple-audio-player
                                :autoplay t))

(setf (cl-sap:sap-source *player*) *url*)

love5an: (R)
Вынесу свой коммент с ЛОРа.

Есть три базовых вида абстракции:


  • На потоках(функциональная)

  • На состоянии(процедурная/оо)

  • Синтаксическая.



Синтаксическая абстракция - важная и, даже наверное, главнейшая часть метапрограммирования. Суть синтаксической абстракции - упрощение нотации в угоду предметной области. Во вменяемом виде она доступна только в диалектах лиспа, т.к:


  • Практически все другие языки программирования ради синтаксической абстракции заставляют нас переизобретать интерпретаторы и компиляторы(а это - невероятно сложное и нуднейшее занятие, потому кстати и малораспространенное - максимум, разве что, время от времени всплывают выродки на XML(maven'ы всякие, XAML и т.д.), плюс встраиваемый JS и всякое Lua - кривые и неудобные языки, отвратительнейше интегрирующиеся с нижележащей платформой).

  • В лиспе синтаксическая абстракция, кроме прочего, не лишает нас ни встроенных средств языка, ни возможностей комбинировать разные API построенные c использованием оной абстракции(чего не скажешь о интерпретаторах, см. выше).



Во-вторых, в том же CL кроме синтаксической абстракции доступны как модификация кода в рантайме, так и метаобъектный протокол. Эти два вида метапрограммирования, на самом деле, относятся ко второму вида а.(на объектах), и оба - гораздо менее мощны, чем синтаксическая абстракция(хотя и реализованы в CL на порядок приятнее и удобнее, чем во множестве других языков).
love5an: (R)
http://spb.hh.ru/article/14852

«»Самой редкой профессией в России стал Lisp-программист. По итогам 2013 г. на сайте hh.ru не было ни одной вакансии на эту должность (в 2011-2012 гг. не более двух).»
love5an: (R)
У меня тут появилась идея проекта.

Вобщем, суть в чем:

Сайт, на котором собраны сниппеты кода на разных языках программирования и не только программирования(sql там и т.п.). Плюс теги, некоторая категоризация, ну и комменты там и так далее.

Сниппеты на самые разные темы, от HelloWorld до коннекта к конкретной БД.

Я думаю, это будет пользоваться популярностью и вот почему:

Несмотря на обилие опенсорса в наши дни, на самом деле всем лень смотреть полноценные проекты на github и подобных порталах. Всем лень читать документацию. Люди хотят набирать в гугле "connect to mysql from erlang" или "make http request in ruby" и получать код, который можно скопипастить. Ну, по крайней мере, подавляющее большинство программистов такого хотят это уж точно, даже если и скрывают.

Такая вот идея.

Что думаете?

UPD: Да, уже сказали про RosettaCode, но имхо там отвратительный интерфейс и wiki-движок. Крайне неудобно.
love5an: (R)
Я тут запушил на гитхаб разные свои утилиты для CL, может еще кому надо.
Они завязаны на SBCL в некоторых местах(md5 из SBCL, pathnames, sb-cltl2 для интроспекции), но по идее, как минимум пару вещей переносимой сделать точно можно.
https://github.com/Lovesan/lvsn-utils

erlman

Jan. 24th, 2014 10:29 pm
love5an: (R)
Я тут написал простенькую утилиту под винду чтоб смотреть доки по OTP
может еще кому надо:
https://github.com/Lovesan/erlman
love5an: (R)
Работаю уже почти месяц эрлангистом(пока что больше сишником, конечно, но тем не менее), и по этому поводу хочу сделать официальное заявление.

Concurrent и distributed программы ни на чем, кроме эрланга, нельзя писать в принципе.
Просто нельзя.
Даже, в принципе, на лиспах.
Потому что то что выходит это полный треш и угар, по сравнению с Э.

Эрланг это такая воплотившаяся мечта сишников писать многопоточный и распределенный код, и работать с асинхронным i/o, так же просто и быстро, как с перекладыванием байтиков. Впрочем, с последним в эрланге тоже все крайне неплохо, следует отметить, если не считать производительности(например чего только стоит паттерн-матчинг по битам).
love5an: (R)
Народ, я тут устроился эрлангистом, буквально сегодня был первый рабочий день.
Возник такой вопрос - какие книжки порекомендуете почитать? Ну и вообще, статьи, другую литературу, howto, etc.
(Исключая Мегакурс Царёва(http://erlang-mnesia-video.ru/), ессно, это уже освоил в полной мере)


BTW: Это вполне повод добавить жж в списки рассылок по тегу erlang, я думаю, буду и про него(не только про лисп) писать в будущем

PS: В качестве объявления - завтра в Питере в 19.00, в Молли Шелтер, собираемся попить пива. Приглашаются лисперы, сочувствующие, да и вообще все кто желает
love5an: (R)
Мы тут в чятике придумали отличную идею для стартапа.
И заодно, для повышения популярности лиспа.

Надо написать на CL хреновину, которая занимает много кода, но нихрена не делает кроме пробрасывания вызовов одних функций в другие.
Придумать солидное название.
И главное, обозвать Enterprise Application Server.
А лучше Dynamic Enterprise Application Server.
Или даже Cloud Dynamic Enterprise Application Server.
И продать Ораклу.
Думаю, это неплохая идея для стартапа.

Есть даже некоторые наброски исходников(это вторая версия кода, в первой были недостаточно длинные идентификаторы):


(let ((core (dserver.application.core.runtime:retrieve-instance
             'dserver.application.core:application-core)))
  (dserver.application.core.runtime:initialize-core
      core
     'dserver.application.core.runtime:application-runtime
     :multiple-use))



Достаточно ли солидно смотрится, как думаете?

При продаже Ораклу можно давить на то что у них совершенно устаревшие технологии, а у нас Dynamic Application Server, а не просто Application Server, которые уже не модны.

Рынок как никогда нуждается в масштабируемых расширяемых динамических серверах приложений.

Я считаю, нам по силам организовать прорыв в таких областях, как предоставление отказоусточивых(24/7) высоконагруженных систем в корпоративном секторе, или же в любой другой сфере, требующей продуманной расширяемой и масштабируемой архитектуры с длинными идентификаторами.

Не секрет, что на текущий момент рынок таких систем нуждается в революционном решении! Такое решение как раз вполне по силам предоставить специалистам моего профиля.
love5an: (R)

public static void CallWithEscapeContinuation(Action<Action> f)
{
  var escapeTag = new Exception();
  Action escapeProcedure = () => { throw escapeTag; };
  try
  {
    f(escapeProcedure);
  }
  catch (Exception e)
  {
    if (ReferenceEquals(escapeTag, e)) return;
    throw;
  }
}

love5an: (R)
На дворе 2013 год, а люди продолжают думать что макросы и метапрограммирование "не нужны". В том числе потому есть HOF, бла бла бла.

http://it-talk.org/post83120.html

Странные люди, на самом деле.

У меня создается впечатление, что они никогда не работали с достаточно крупными приложениями, и черпают свои "гениальные" теории из диванного теоретизирования после написания очередного хелловорлда на каком-нибудь хаскеле.

Вот я сейчас на работе участвую в разработке и кастомизации внушительного такого размера трейдинг-системы.
Казалось бы, суровый энтерпрайз. Опять же, дотнет.
Но тем не менее, метапрограммирование - повсюду. Серьезно - и кодогенерация, и так далее. И причем, это не только в самой нашей системе(в которой метапрограммирование везде, от веб-сервисов до FIX-протокола), но так и вообще, во множестве инструментов и фреймворков от Microsoft(взять тот же ORM слой, ну например Entity Framework, или GUI - XAML). И я думаю, с Java ситуация была бы абсолютно аналогичная, и почти во всех крупных проектах на Java так и есть.

А почему люди не понимают этого? Я не знаю, но предположения, конечно, есть. Первое из таких я выше озвучил, а второе в том - что люди просто принципиально не осознают что такое макросы в частности и метапрограммирование вообще.

Народ, метапрограммирование и макросы - это не очередной хитрый способ "красиво и за меньше количество строчек писать циклы"(об этом как раз HOF, и сишный препроцессор, отчасти). Это инструмент для повышения абстракции, причем один из фундаментальнейших, наряду с теми же функциями/процедурами и структурами данных.

Языки или платформы без возможностей метапрограммирования - бедны и убоги, либо же крайне узко специализированы.
love5an: (R)
Главная проблема у first-class продолжений в том, что они устраняют понятие dynamic-extent, то есть контекста с динамическим временем жизни, а соответственно:

Во-первых, делают невозможной строгую стековую модель исполнения, а это значит, что никакие формы управления потоком вычислений основанные на оной модели(например все коммонлисповые - tagbody+go, block+return-from, throw+catch, unwind-protect) не могут быть нормально реализованы(они, во-первых, просто теряют смысл, а во-вторых их семантику становится легко, случайно и непреднамеренно даже, сломать, использовав продолжения).

Во-вторых, так как у нас теряется понятие dynamic extent, то все first-class и second-class сущности, включая теперь и собственно поток вычислений, получают unlimited extent, а значит мы теперь не можем детерминированно управлять временем жизни неуправляемых ресурсов, навроде файловых дескрипторов.

В-третьих, продолжения несут громаднейший оверхед. Мы получаем просто невероятно дикую неэффективность, как по памяти, так и по производительности, во-первых из-за того что вынуждены хранить фреймы активации в динамической памяти, и не можем использовать стек и все его плюшки(включая машинные инструкции для работы с ним и бонусы от локальности памяти), а во-вторых из-за того, что компилятору становятся практически недоступны все нелокальные оптимизации, так как у него нет гарантий относительно хода исполнения программы. Некоторые оптимизирующие компиляторы Scheme, в основном коммерческие, проводят небольшие оптимизации в этом плане, когда возможно складывая некоторые фреймы на стек например, но тем не менее, оптимизации эти возможны далеко не всегда, и они неслабо так усложняют компиляторы.

call/ep

Jan. 5th, 2013 09:31 pm
love5an: (R)
Я тут почитываю Lisp in Small Pieces. Крайне интересная книжка, рекомендую.

Решил поделиться следующим фактом.

Для того, чтобы реализовать всю семантику контроля потоком вычислений Common Lisp, включая в том числе обработку исключений CL, нужно чтобы язык поддерживал Escape Continuations.

А конкретнее, необходимо реализовать процедуру call/ep, или аналогичный макрос let/ep

call/ep имеет тот же интерфейс, как и call/cc, с тем лишь отличием, что процедура-продолжение, передаваемая в параметр функции становится невалидной сразу после выхода из фрейма активации этой функции. То есть, мы можем "выйти" из функции/блока, но зайти в него снова, как мы могли бы это сделать с полноценными продолжениями - мы не можем.

Вот как эта процедура пишется на CL.


(defun call/ep (f)
  (block exit-point
    (labels ((escape-procedure (arg)
               (return-from exit-point arg)))
      (funcall f #'escape-procedure))))

(defmacro let/ep ((var) &body body)
  (let ((block (gensym "EXIT-POINT"))
        (escape-procedure (gensym "ESCAPE-PROC"))
        (arg (gensym "ARG")))
    `(block ,block
       (labels ((,escape-procedure (,arg)
                  (return-from ,block ,arg)))
         (let ((,var #',escape-procedure))
           ,@body))))) 



Фактически, для полноценных escape-продолжений нам необходимо лишь реализовать базис в виде двух операторов/функций - throw и catch(или, что то же самое - block и return-from). Желательно, конечно, чтобы в базисе был еще и unwind-protect, но имея упомянутые два оператора, мы можешь написать его и сами.

Как несложно догадаться, все это вместе поддается реализации на любом языке, поддерживающем замыкания и исключения(или же setjmp+longjmp). Замыкания, впрочем, можно заменить объектами, но в таком случае всё это дело будет смотреться более громоздко.

Profile

love5an: (Default)
Dmitry Ignatiev

December 2016

S M T W T F S
    123
45678910
11121314 151617
18192021222324
25262728293031

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 20th, 2017 12:49 pm
Powered by Dreamwidth Studios