Smalltalk › русский язык (Russian)

Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

87 messages Options

12345

Dennis Schetinin

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

И ты молчишь?! …А дашь посмотреть? :)

Серьезно, выложи куда-нибудь, чтобы забрать можно было.

Best regards,

Dennis Schetinin

24 октября 2013 г., 12:26 пользователь Denis Kudriashov <[hidden email]> написал:

На Esug2012 была представлена именно такая система. У меня есть даже имидж с демой. Правда я его так и не запускал, могу поделиться.
http://prezi.com/ysvlqroq5vr2/ooscm-esug-presentation/

Но проблема в том, что монтичело всех вполне устраивает. Иначе и монтичело2 уже давно бы использовался. Когда я спросил в фаро-листе, хотят ли они подобную семантическую систему управления кодом, ответ был прост: а кто будет ее поддерживать? Монтичело взрослая система, с ней все ясно. Чтобы начали использовать что-то другое, кто-то должен серьезно это продвигать. Причем, есть еще тенденция перейти на гит.

Кстати, интересно, по рассказам одного немца, для долфина всегда была такая система, и они ее реально использовали на практике. Правда это была просто объектная база данных с поддержой версионности. Он говорил, что никаких специальных средств и не надо, код это же просто набор объектов.

24 октября 2013 г., 9:38 пользователь Dennis Schetinin <[hidden email]> написал:

Давно думаю и редко пытаюсь озвучить, что Smalltalk-у стыдно не иметь системы управления кодом, которая основывается на действиях пользователя, а не анализе текстов… Но это — отдельная тема, конечно. :)

--
Best regards,

Dennis Schetinin

23 октября 2013 г., 12:46 пользователь Semyon Novikov <[hidden email]> написал:

Про мерджинг забыл ответить, в том-то и дело, что конфликты бывали почти всегда, причем многие тот же меркуриал размерджил бы сам, а вот монтичелло не справился. Хотя, казалось бы, у него семантический мерж, а не строковый.

2013/10/23 Semyon Novikov <[hidden email]>

Ну, я все-таки годами с ним не работал, описал субъективные ощущения. Про ветки, кстати, не знал. спасибо!

2013/10/23 Юрий Мироненко <[hidden email]>

Или у вас карма плохая, или вы что-то делали не так.

Мержить приходилось просто каждый коммит.

Да, так и надо. Если я правильно вас понял, конечно.
То есть, когда вы загружаете версию из репозитория, вы пользуетесь методом merge, и если возникают конфликты - вы их разрешаете.
А в чём проблема?
Как бы вы хотели это делать?

Это уже просто в подкорке сидит: начал делать что-то новое, сделай ветку и делай в ней. Тут так не получается, понятное дело.

Почему не получается? У каждого snapshot'а есть ancestors'ы. От одного ancestor'а может быть унаследовано несколько разных веток, и идти совершенно независимо друг от друга. Ancestors'ов может быть несколько, поэтому можно сливать эти ветки в какой угодно комбинации.

Единственно - визуальный интерфейс специально на работу с ветками не заточен. И разделять именование файлов, относящихся к разным веткам, приходится вручную.

Один раз приятель умудрился закоммитить mcz, который оказался битым архивом. Как это было возможно я не очень представляю.

Есть ровно одна серьёзная проблема с monticello - он не любит, когда комментарии к snapshot'у делаются на русском. При этом как раз получаются "битые архивы" и "инфернальные исключения". Ну, тут решение простое - не писать комментарии по-русски. Неприятно, да.

Я годами работаю с monticello, в группах вплоть до четырёх человек (правда, четыре человека было недолго) держу вполне коммерческие репозитарии на сквиксорсе и жемстоуновской реинкарнации сквиксорса. И, за исключением случаев, когда падал сервер с репозитариями, особенно серьёзных проблем не получал. И ещё - за исключением самого-самого начала, когда я ещё не понимал, как он работает.

Это письмо так и следует понимать. Я не пытаюсь сказать "вы всё врёте". Я пытаюсь понять, какие были проблемы, и рассказать, отчего они получаются.

23 октября 2013 г., 7:37 пользователь Semyon Novikov <[hidden email]> написал:

Обещал про монтичелло рассказать.
В общем как-то раз у нас с приятелем уехали жёны, одновременено.
Ну и мы, как два дурака вместо того чтобы нажраться на кухне под селёдку решили устроить мини-хакатон. Писали "дата-майнер" по куче новостных фидов финансовой тематики, без особой цели, скажем так, с целью поиска закономерностей и весело превести время.

Подняли ftp-репозиторий под это дело и начали фигачить. Так как нас было всего двое, проект был маленький, и мы писали почти сутки, мы огребли такое количество проблем с мерджингом, сколько я даже в svn не получал. Мержить приходилось просто каждый коммит. Потому что монтичелло не хранит changeset'ы, он хранит snapshot'ы. Очень нехватало feature branches, как в hg или git. Это уже просто в подкорке сидит: начал делать что-то новое, сделай ветку и делай в ней. Тут так не получается, понятное дело.

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

Один раз приятель умудрился закоммитить mcz, который оказался битым архивом. Как это было возможно я не очень представляю.

В общем это был травматичный опыт.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

Denis Kudriashov

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

In reply to this post by semka.novikov

24 октября 2013 г., 20:30 пользователь <[hidden email]> написал:

Ну, я писал, что куча языков кроме Смолтока так умеет. Да и пообще сравнивать Си и Smalltalk довольно странно.

ТДД для того и придуман, чтобы тесты падали, когда что-то меняется, я не вижу особой проблемы в том, что вы описали, если честно 😊

Суть в том, что вы не запустите ваш тест пока вся ваша система не будет избавлена от ошибок компиляции, что убивает весь процесс TDD

Denis Kudriashov

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

In reply to this post by Dennis Schetinin

24 октября 2013 г., 21:02 пользователь Dennis Schetinin <[hidden email]> написал:

Переезд на гит означает окончательное укоренение исходников в коде — подозреваю, после этого к объектам путь будет заказан на долгие годы.

Как я понимаю, для пользователей фары переход будет тривиальным. Просто добавляется новый тип репозитория (к директории, http, ftp и magma). Так что для конечного пользователя ничего, по сути, не изменится, все будет работать через стандартные тулзы. По крайней мере я так вижу :)

Denis Kudriashov

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

In reply to this post by Dennis Schetinin

24 октября 2013 г., 21:17 пользователь Dennis Schetinin <[hidden email]> написал:

И ты молчишь?! …А дашь посмотреть? :)

Серьезно, выложи куда-нибудь, чтобы забрать можно было.

Уверен, тебе об этом рассказывал :). В общем, постараюсь выложить куда-нидь. Хотя лучше попросить у автора, и версия, наверное, более актуальная будет. Возможно, проект уже где-то опубликован типа сквиксорса

Denis Kudriashov

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

In reply to this post by Dennis Schetinin

24 октября 2013 г., 21:02 пользователь Dennis Schetinin <[hidden email]> написал:

Переезд на гит означает окончательное укоренение исходников в коде — подозреваю, после этого к объектам путь будет заказан на долгие годы.

И как я уже говорил, монтичело всех устраивает более чем (кстати она появилась до гита), А с появлением smalltalkhub-а и гитхаб особо не актуален, на мой взгляд

semka.novikov

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

In reply to this post by Denis Kudriashov

Да где ж я такое написал?

Отправлено с беспроводного устройства BlackBerry®

From: Denis Kudriashov <[hidden email]>

Sender: [hidden email]

Date: Thu, 24 Oct 2013 23:18:42 +0400

To: sugr<[hidden email]>

ReplyTo: [hidden email]

Subject: Re: [RSUG] Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

24 октября 2013 г., 20:30 пользователь <[hidden email]> написал:

Ну, я писал, что куча языков кроме Смолтока так умеет. Да и пообще сравнивать Си и Smalltalk довольно странно.

ТДД для того и придуман, чтобы тесты падали, когда что-то меняется, я не вижу особой проблемы в том, что вы описали, если честно 😊

semka.novikov

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

In reply to this post by Denis Kudriashov

Ну, если бы монтичелло прямо всех устраивал, никто и не думал бы о переезде на гит :)

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

От: [hidden email]
Отправлено: четверг, 24 октября 2013 г. 23:32
Кому: [hidden email]

24 октября 2013 г., 21:02 пользователь Dennis Schetinin <[hidden email]> написал:

Переезд на гит означает окончательное укоренение исходников в коде — подозреваю, после этого к объектам путь будет заказан на долгие годы.

semka.novikov

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

In reply to this post by Dennis Schetinin

Это прозвучало как “окончательно укоренение программ в байтах, подозреваю после этого путь к магическим шарам будет заказан”.

А где по-вашему код в итоге оказывается? Чем отличается дамп состояния объектов от такого же дампа, только текстом?

От: [hidden email]
Отправлено: четверг, 24 октября 2013 г. 21:02
Кому: [hidden email]

Переезд на гит означает окончательное укоренение исходников в коде — подозреваю, после этого к объектам путь будет заказан на долгие годы.

Best regards,

Dennis Schetinin

24 октября 2013 г., 17:00 пользователь Semyon Novikov <[hidden email]> написал:

Дороговизна в том, что семантические штуки хорошо работают только с тем языком, для которого они предназначены. Я от переключения между git и mercurial уже тихонько с ума схожу, если сюда добавить еще третью VCS, которая работает только со Smalltalk у меня будет удар.

То есть, писать их все равно надо и это сложнее, чем написать очередной гит. Но при этом использовать её можно только для хранения кода на одном языке. Вот поэтому и дорого.

А чем плох переезд на гит, если развернуто.

2013/10/24 Dennis Schetinin <[hidden email]>

А в чем дороговизна?

И я по-прежнему считаю, что переход на гит будет началом убивания Smalltalk-а.

--
Best regards,

Dennis Schetinin

24 октября 2013 г., 13:14 пользователь Semyon Novikov <[hidden email]> написал:

На самом деле системы семантического мержа/хранения штука, конечно, интересная, но неоправдано дорогая получается.
Собственно потому ими никто и не пользуется. Какие-то зачатки есть в монтичелло, что-то для дотнета есть в TFS и всё, получается. Больше я ни о чем не слышал, по крайней мере.

Переезд на гит, кстати, это суперздравая идея. Хотя я сам гит не то чтобы очень люблю, но он победил.

Презентация офигенная.

2013/10/24 Denis Kudriashov <[hidden email]>

На Esug2012 была представлена именно такая система. У меня есть даже имидж с демой. Правда я его так и не запускал, могу поделиться.
http://prezi.com/ysvlqroq5vr2/ooscm-esug-presentation/

Но проблема в том, что монтичело всех вполне устраивает. Иначе и монтичело2 уже давно бы использовался. Когда я спросил в фаро-листе, хотят ли они подобную семантическую систему управления кодом, ответ был прост: а кто будет ее поддерживать? Монтичело взрослая система, с ней все ясно. Чтобы начали использовать что-то другое, кто-то должен серьезно это продвигать. Причем, есть еще тенденция перейти на гит.

Кстати, интересно, по рассказам одного немца, для долфина всегда была такая система, и они ее реально использовали на практике. Правда это была просто объектная база данных с поддержой версионности. Он говорил, что никаких специальных средств и не надо, код это же просто набор объектов.

24 октября 2013 г., 9:38 пользователь Dennis Schetinin <[hidden email]> написал:

Давно думаю и редко пытаюсь озвучить, что Smalltalk-у стыдно не иметь системы управления кодом, которая основывается на действиях пользователя, а не анализе текстов… Но это — отдельная тема, конечно. :)

--
Best regards,

Dennis Schetinin

23 октября 2013 г., 12:46 пользователь Semyon Novikov <[hidden email]> написал:

Про мерджинг забыл ответить, в том-то и дело, что конфликты бывали почти всегда, причем многие тот же меркуриал размерджил бы сам, а вот монтичелло не справился. Хотя, казалось бы, у него семантический мерж, а не строковый.

2013/10/23 Semyon Novikov <[hidden email]>

Ну, я все-таки годами с ним не работал, описал субъективные ощущения. Про ветки, кстати, не знал. спасибо!

2013/10/23 Юрий Мироненко <[hidden email]>

Или у вас карма плохая, или вы что-то делали не так.

Мержить приходилось просто каждый коммит.

Да, так и надо. Если я правильно вас понял, конечно.
То есть, когда вы загружаете версию из репозитория, вы пользуетесь методом merge, и если возникают конфликты - вы их разрешаете.
А в чём проблема?
Как бы вы хотели это делать?

Это уже просто в подкорке сидит: начал делать что-то новое, сделай ветку и делай в ней. Тут так не получается, понятное дело.

Почему не получается? У каждого snapshot'а есть ancestors'ы. От одного ancestor'а может быть унаследовано несколько разных веток, и идти совершенно независимо друг от друга. Ancestors'ов может быть несколько, поэтому можно сливать эти ветки в какой угодно комбинации.

Единственно - визуальный интерфейс специально на работу с ветками не заточен. И разделять именование файлов, относящихся к разным веткам, приходится вручную.

Один раз приятель умудрился закоммитить mcz, который оказался битым архивом. Как это было возможно я не очень представляю.

Есть ровно одна серьёзная проблема с monticello - он не любит, когда комментарии к snapshot'у делаются на русском. При этом как раз получаются "битые архивы" и "инфернальные исключения". Ну, тут решение простое - не писать комментарии по-русски. Неприятно, да.

Я годами работаю с monticello, в группах вплоть до четырёх человек (правда, четыре человека было недолго) держу вполне коммерческие репозитарии на сквиксорсе и жемстоуновской реинкарнации сквиксорса. И, за исключением случаев, когда падал сервер с репозитариями, особенно серьёзных проблем не получал. И ещё - за исключением самого-самого начала, когда я ещё не понимал, как он работает.

Это письмо так и следует понимать. Я не пытаюсь сказать "вы всё врёте". Я пытаюсь понять, какие были проблемы, и рассказать, отчего они получаются.

23 октября 2013 г., 7:37 пользователь Semyon Novikov <[hidden email]> написал:

Обещал про монтичелло рассказать.
В общем как-то раз у нас с приятелем уехали жёны, одновременено.
Ну и мы, как два дурака вместо того чтобы нажраться на кухне под селёдку решили устроить мини-хакатон. Писали "дата-майнер" по куче новостных фидов финансовой тематики, без особой цели, скажем так, с целью поиска закономерностей и весело превести время.

Подняли ftp-репозиторий под это дело и начали фигачить. Так как нас было всего двое, проект был маленький, и мы писали почти сутки, мы огребли такое количество проблем с мерджингом, сколько я даже в svn не получал. Мержить приходилось просто каждый коммит. Потому что монтичелло не хранит changeset'ы, он хранит snapshot'ы. Очень нехватало feature branches, как в hg или git. Это уже просто в подкорке сидит: начал делать что-то новое, сделай ветку и делай в ней. Тут так не получается, понятное дело.

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

Один раз приятель умудрился закоммитить mcz, который оказался битым архивом. Как это было возможно я не очень представляю.

В общем это был травматичный опыт.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

semka.novikov

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

In reply to this post by Denis Kudriashov

У нас с вами какие-то очень разные представления о ТДД, по-моему. А ещё тут некоторое непонимание устройства современных компиляторов есть.

ТДД это штука, которая гарантирует определенный (невысокий, кстати) уровень непротиворечивости кода в тот момент, когда тесты зелёные. Так же в её обязанности входит просигнализировать когда состояние становится противоречивым.

Когда проект не собирается -- это явно противоречивое состояние. И тесты обязаны падать. Вспомните, как Бек описывал ТДД:

Пишем тест, который использует несуществующий еще код
Программа не собирается (~ тест не работает)
Пишем код
Запускаем тест

То есть состояние “разваленного проекта” для ТДД более чем естественно.

Но даже если вы думаете иначе, у меня два возражения:

Если вы внимательно посмотрите на любой современный компилятор практически любого языка, то увидите, что единицей компиляции является не проект, а файл. Нет нужды пересобирать тот код, который не менялся, собирается только нужный для получения актуального состояния. То есть я написал тест, скомпилировал, собрался только этот тест. Более того, как правило тесты это отдельная цель компиляции, а проект к ним тем или иным способом линкуется. То есть я могу вообще не иметь исходниов проекта, чтобы писать к нему тесты. Так что единственным требованием для работы тестов в том же objc является нормальность самих тестов.
Если вы поменяли что-то в проекте и у вас развалились тесты, вам совершенно неважно, запускается только что написанный тест или нет. У вас есть более важные проблемы -- падает туева хуча тестов. Это форс-мажор, надо бросать все и чинить. А к работоспособности текущего теста можно и попозже вернуться.

Ну и последнее, возможность компиляции отдельных методов это, конечно, круто и удобно для написания тестов. Но учитывая наличие у некоторых из “некошерных” языков нормальных систем типизации (Scala, F#, OCaml, Haskell, etc), вопрос встает совершенно иным боком. Процентов 70 тестов, которые я вынужден писать для Objective-C (прямой потомок St) просто нет смысла писать на хаскеле. Там подобные вещи на этапе компиляции выясняются автоматически, без тестов.

От: [hidden email]
Отправлено: ‎четверг‎, ‎24‎ ‎октября‎ ‎2013‎ г. ‎23‎:‎18
Кому: [hidden email]

24 октября 2013 г., 20:30 пользователь <[hidden email]> написал:

Ну, я писал, что куча языков кроме Смолтока так умеет. Да и пообще сравнивать Си и Smalltalk довольно странно.

ТДД для того и придуман, чтобы тесты падали, когда что-то меняется, я не вижу особой проблемы в том, что вы описали, если честно 😊

Dennis Schetinin

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

In reply to this post by semka.novikov

А где по-вашему код в итоге оказывается? Чем отличается дамп состояния объектов от такого же дампа, только текстом?

Да, в итого, он, по всей видимости, оказывается на гитхабе…

А дамп состояния от такого же дампа действительно мало чем отличается — это все только состояние, зафиксированное состояние — то есть, смерть. Нужно препарировать труп — анализировать текст, — чтобы понять, что с ним происходило. Даже просто отследить, что вот этот кусок текста — это имя переменной, и что он превратился в вон тот кусок текста (переменную переименовали),— уже очень сложно.

А если это делать на стадии, когда код еще не превратился в мертвый текст, а состоит из объектов (переменных, методов, посылок сообщений и т.д.)? В этот момент объекты обладают еще и поведением, что делает их живыми. Живой код дает гораздо больше возможностей: например, он может отслеживать, что делает с ним один разработчик, а затем соответствующим образом это учитывать, когда нужно слить эти изменения изменениями другого разработчика.

Допустим, есть метод, один из разработчиков его немного изменил. В это время другой разработчик перетащил этот метод в другой класс. Затрудняюсь представить себе merger, который разрулит эту ситуацию, имея на входе три текста. А вот "объект", который "понимает", что перенос метода в другое место свелся просто к изменению списка входных параметров, вполне может "переварить" изменения внутренностей.

Я на самом деле, ничего нового не придумываю. То, что способ отслеживания изменений кода в современных смоллтоках слишком примитивен, мы обсуждали года 3–4 назад на ESUG-е, и уже тогда нам показывали более развитую систему, которая отслеживала не конечные состояния (как сейчас), а все "дельты" изменений (другое дело, что ни у кого не было времени ее развивать и доводить из стадии прототипа в более-менее готовый вид). Как я понимаю, там даже не обязательно быть в курсе про смысл изменений в большинстве случаев, чтобы получить качественно другую систему управления версиями (с совсем другими возможностями по слиянию изменений). А если большинство изменений в коде будет делаться формализованными операциями (рефакторингами), к которым приписана логика, помогающая позднее слить эти изменения с параллельной веткой (это, по всей вероятности, и называется семантикой?) то, по-моему, вообще можно получить уровень, который просто не мыслим ни для каких гитов.

Разумеется, Денис Кудряшов прав — для конечного пользователя поддержка ГИТ-а станет просто еще одним способом хранения кода. Всего лишь… В какой-то степени это даже сделает Smalltalk ближе к другим современным средствам разработки, станет заметнее. Но тогда будет еще меньше аргументов в пользу того, что надо заниматься качественно другими способами управления программными проектами: "нафига городить огород, если и так все хорошо". Если почти всех почти устраивает монтичела, а с переходом на гитхаб она станет еще больше устраивать еще большее количество людей, то кто станет заниматься чем-то другим? Нет, рано или поздно это, конечно, будет. Но мы можем этого уже и не застать :)

Популярность имеет и обратную сторону. Я бы не сказал, что я в восторге от качества кода, который я вижу в том же Pharo, или который видел в VisualWorks… я уже молчу про Morphic. А если набегут ребята, которые не понимают до конца, не чувствуют что такое Smalltalk… Количество библиотек, конечно увеличится, но вот станет ли от этого легче. Из разговоров с Руби-разработчиками я понял, что это действительно проблема: библиотек и всякого кода — дофига, только найти среди этих залежей что-то путное действительно сложно. То же самое я наблюдаю в Java. Наш продукт сильно нуждается в различных библиотеках, поддерживающих различные протоколы и технологии. И когда нам что-то такое нужно, мы быстро находим соответствующее решение. Но в 99% случаев через некоторое время натыкаемся на всякого рода проблемы, которые не только мы сами, не смотря на открытость исходников, не в состоянии разрулить ("благодаря" качеству этого кода), но и авторы не могу (просто тонут в собственном коде).

В общем, вот… Получилось сумбурно и даже не совсем по теме, но удалять уже жалко :)

Best regards,

Dennis Schetinin

25 октября 2013 г., 7:39 пользователь <[hidden email]> написал:

Это прозвучало как “окончательно укоренение программ в байтах, подозреваю после этого путь к магическим шарам будет заказан”.

А где по-вашему код в итоге оказывается? Чем отличается дамп состояния объектов от такого же дампа, только текстом?

От: [hidden email]
Отправлено: четверг, 24 октября 2013 г. 21:02
Кому: [hidden email]

Переезд на гит означает окончательное укоренение исходников в коде — подозреваю, после этого к объектам путь будет заказан на долгие годы.

--
Best regards,

Dennis Schetinin

24 октября 2013 г., 17:00 пользователь Semyon Novikov <[hidden email]> написал:

Дороговизна в том, что семантические штуки хорошо работают только с тем языком, для которого они предназначены. Я от переключения между git и mercurial уже тихонько с ума схожу, если сюда добавить еще третью VCS, которая работает только со Smalltalk у меня будет удар.

То есть, писать их все равно надо и это сложнее, чем написать очередной гит. Но при этом использовать её можно только для хранения кода на одном языке. Вот поэтому и дорого.

А чем плох переезд на гит, если развернуто.

2013/10/24 Dennis Schetinin <[hidden email]>

А в чем дороговизна?

И я по-прежнему считаю, что переход на гит будет началом убивания Smalltalk-а.

--
Best regards,

Dennis Schetinin

24 октября 2013 г., 13:14 пользователь Semyon Novikov <[hidden email]> написал:

На самом деле системы семантического мержа/хранения штука, конечно, интересная, но неоправдано дорогая получается.
Собственно потому ими никто и не пользуется. Какие-то зачатки есть в монтичелло, что-то для дотнета есть в TFS и всё, получается. Больше я ни о чем не слышал, по крайней мере.

Переезд на гит, кстати, это суперздравая идея. Хотя я сам гит не то чтобы очень люблю, но он победил.

Презентация офигенная.

2013/10/24 Denis Kudriashov <[hidden email]>

На Esug2012 была представлена именно такая система. У меня есть даже имидж с демой. Правда я его так и не запускал, могу поделиться.
http://prezi.com/ysvlqroq5vr2/ooscm-esug-presentation/

Но проблема в том, что монтичело всех вполне устраивает. Иначе и монтичело2 уже давно бы использовался. Когда я спросил в фаро-листе, хотят ли они подобную семантическую систему управления кодом, ответ был прост: а кто будет ее поддерживать? Монтичело взрослая система, с ней все ясно. Чтобы начали использовать что-то другое, кто-то должен серьезно это продвигать. Причем, есть еще тенденция перейти на гит.

Кстати, интересно, по рассказам одного немца, для долфина всегда была такая система, и они ее реально использовали на практике. Правда это была просто объектная база данных с поддержой версионности. Он говорил, что никаких специальных средств и не надо, код это же просто набор объектов.

24 октября 2013 г., 9:38 пользователь Dennis Schetinin <[hidden email]> написал:

Давно думаю и редко пытаюсь озвучить, что Smalltalk-у стыдно не иметь системы управления кодом, которая основывается на действиях пользователя, а не анализе текстов… Но это — отдельная тема, конечно. :)

--
Best regards,

Dennis Schetinin

23 октября 2013 г., 12:46 пользователь Semyon Novikov <[hidden email]> написал:

Про мерджинг забыл ответить, в том-то и дело, что конфликты бывали почти всегда, причем многие тот же меркуриал размерджил бы сам, а вот монтичелло не справился. Хотя, казалось бы, у него семантический мерж, а не строковый.

2013/10/23 Semyon Novikov <[hidden email]>

Ну, я все-таки годами с ним не работал, описал субъективные ощущения. Про ветки, кстати, не знал. спасибо!

2013/10/23 Юрий Мироненко <[hidden email]>

Или у вас карма плохая, или вы что-то делали не так.

Мержить приходилось просто каждый коммит.

Да, так и надо. Если я правильно вас понял, конечно.
То есть, когда вы загружаете версию из репозитория, вы пользуетесь методом merge, и если возникают конфликты - вы их разрешаете.
А в чём проблема?
Как бы вы хотели это делать?

Это уже просто в подкорке сидит: начал делать что-то новое, сделай ветку и делай в ней. Тут так не получается, понятное дело.

Почему не получается? У каждого snapshot'а есть ancestors'ы. От одного ancestor'а может быть унаследовано несколько разных веток, и идти совершенно независимо друг от друга. Ancestors'ов может быть несколько, поэтому можно сливать эти ветки в какой угодно комбинации.

Единственно - визуальный интерфейс специально на работу с ветками не заточен. И разделять именование файлов, относящихся к разным веткам, приходится вручную.

Один раз приятель умудрился закоммитить mcz, который оказался битым архивом. Как это было возможно я не очень представляю.

Есть ровно одна серьёзная проблема с monticello - он не любит, когда комментарии к snapshot'у делаются на русском. При этом как раз получаются "битые архивы" и "инфернальные исключения". Ну, тут решение простое - не писать комментарии по-русски. Неприятно, да.

Я годами работаю с monticello, в группах вплоть до четырёх человек (правда, четыре человека было недолго) держу вполне коммерческие репозитарии на сквиксорсе и жемстоуновской реинкарнации сквиксорса. И, за исключением случаев, когда падал сервер с репозитариями, особенно серьёзных проблем не получал. И ещё - за исключением самого-самого начала, когда я ещё не понимал, как он работает.

Это письмо так и следует понимать. Я не пытаюсь сказать "вы всё врёте". Я пытаюсь понять, какие были проблемы, и рассказать, отчего они получаются.

23 октября 2013 г., 7:37 пользователь Semyon Novikov <[hidden email]> написал:

Обещал про монтичелло рассказать.
В общем как-то раз у нас с приятелем уехали жёны, одновременено.
Ну и мы, как два дурака вместо того чтобы нажраться на кухне под селёдку решили устроить мини-хакатон. Писали "дата-майнер" по куче новостных фидов финансовой тематики, без особой цели, скажем так, с целью поиска закономерностей и весело превести время.

Подняли ftp-репозиторий под это дело и начали фигачить. Так как нас было всего двое, проект был маленький, и мы писали почти сутки, мы огребли такое количество проблем с мерджингом, сколько я даже в svn не получал. Мержить приходилось просто каждый коммит. Потому что монтичелло не хранит changeset'ы, он хранит snapshot'ы. Очень нехватало feature branches, как в hg или git. Это уже просто в подкорке сидит: начал делать что-то новое, сделай ветку и делай в ней. Тут так не получается, понятное дело.

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

Один раз приятель умудрился закоммитить mcz, который оказался битым архивом. Как это было возможно я не очень представляю.

В общем это был травматичный опыт.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

Dennis Schetinin

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

In reply to this post by semka.novikov

Наши представления о TDD с Денисом довольно сильно совпадают. А с изложенными вами — нет. Поэтому позволю себе "встрять". (Хотя, мы же это уже обсуждали, разве нет?)

Иногда мне надо проверить маленькую идею. Чтобы ее проверить мне нужно всего лишь написать пару–тройку тестов в моей системе, и при этом в исходники внести какие-то изменения. Но, допустим, эти изменения приводят к возникновению логических противоречий (и, соответственно, совместимости типов) с другими частями системы (которых я не касаюсь в рамках проверки данной гипотезы), а чтобы устранить их, мне нужно "перелопатить" всю систему. Smalltalk с его динамической типизацией позволяет этого не делать, просто быстро реализовать самое необходимое, запустить такую полу-готовую (half-baked) систему, проверить идеи и либо отказаться, либо двигаться дальше. Система со статической типизацей, как я понимаю, не даст мне это сделать, пока я не уберу все логические противоречия. По крайней мере, в C++/C#/Java все обстоит именно так, разве нет? Правильная типизация как-то снимает эту проблему?

Best regards,

Dennis Schetinin

25 октября 2013 г., 7:42 пользователь <[hidden email]> написал:

У нас с вами какие-то очень разные представления о ТДД, по-моему. А ещё тут некоторое непонимание устройства современных компиляторов есть.

ТДД это штука, которая гарантирует определенный (невысокий, кстати) уровень непротиворечивости кода в тот момент, когда тесты зелёные. Так же в её обязанности входит просигнализировать когда состояние становится противоречивым.

Когда проект не собирается -- это явно противоречивое состояние. И тесты обязаны падать. Вспомните, как Бек описывал ТДД:

Пишем тест, который использует несуществующий еще код

Программа не собирается (~ тест не работает)

Пишем код

Запускаем тест

То есть состояние “разваленного проекта” для ТДД более чем естественно.

Но даже если вы думаете иначе, у меня два возражения:

Если вы внимательно посмотрите на любой современный компилятор практически любого языка, то увидите, что единицей компиляции является не проект, а файл. Нет нужды пересобирать тот код, который не менялся, собирается только нужный для получения актуального состояния. То есть я написал тест, скомпилировал, собрался только этот тест. Более того, как правило тесты это отдельная цель компиляции, а проект к ним тем или иным способом линкуется. То есть я могу вообще не иметь исходниов проекта, чтобы писать к нему тесты. Так что единственным требованием для работы тестов в том же objc является нормальность самих тестов.

Если вы поменяли что-то в проекте и у вас развалились тесты, вам совершенно неважно, запускается только что написанный тест или нет. У вас есть более важные проблемы -- падает туева хуча тестов. Это форс-мажор, надо бросать все и чинить. А к работоспособности текущего теста можно и попозже вернуться.

Ну и последнее, возможность компиляции отдельных методов это, конечно, круто и удобно для написания тестов. Но учитывая наличие у некоторых из “некошерных” языков нормальных систем типизации (Scala, F#, OCaml, Haskell, etc), вопрос встает совершенно иным боком. Процентов 70 тестов, которые я вынужден писать для Objective-C (прямой потомок St) просто нет смысла писать на хаскеле. Там подобные вещи на этапе компиляции выясняются автоматически, без тестов.

От: [hidden email]
Отправлено: ‎четверг‎, ‎24‎ ‎октября‎ ‎2013‎ г. ‎23‎:‎18
Кому: [hidden email]

24 октября 2013 г., 20:30 пользователь <[hidden email]> написал:

Ну, я писал, что куча языков кроме Смолтока так умеет. Да и пообще сравнивать Си и Smalltalk довольно странно.

ТДД для того и придуман, чтобы тесты падали, когда что-то меняется, я не вижу особой проблемы в том, что вы описали, если честно 😊

Суть в том, что вы не запустите ваш тест пока вся ваша система не будет избавлена от ошибок компиляции, что убивает весь процесс TDD

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

semka.novikov

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

Да, вы совершенно верно всё понимаете, в языках с развитой статической типизацией нет способа внести в систему типизационное противоречие даже “на время”. Точнее есть, но они все проходят под общим названием “Костыли” :)

Так что если вы делаете что-то для проверки, что совершенно не вписывается в текущую архитектуру, проще сделать прототип отдельно, но обычно не приходится.

Пару месяцев назад у нас уже был холивар на эту тему, мнение моё не поменялось. Я, например, дурак невнимательный и если я вношу изменения, которые конфликтуют с существующей архитектурой, я хочу узнать об этом как можно раньше. Иначе я просто забуду и задеплою кривой код. Вот ради уверенности я готов пожертвовать удобством создания “быстрых прототипов” по схеме динамической типизации. Есть способы быстро прототипировать и с типами, просто они другие.

От: [hidden email]
Отправлено: ‎суббота‎, ‎26‎ ‎октября‎ ‎2013‎ г. ‎12‎:‎40
Кому: [hidden email]

Best regards,

Dennis Schetinin

25 октября 2013 г., 7:42 пользователь <[hidden email]> написал:

У нас с вами какие-то очень разные представления о ТДД, по-моему. А ещё тут некоторое непонимание устройства современных компиляторов есть.

ТДД это штука, которая гарантирует определенный (невысокий, кстати) уровень непротиворечивости кода в тот момент, когда тесты зелёные. Так же в её обязанности входит просигнализировать когда состояние становится противоречивым.

Когда проект не собирается -- это явно противоречивое состояние. И тесты обязаны падать. Вспомните, как Бек описывал ТДД:

Пишем тест, который использует несуществующий еще код

Программа не собирается (~ тест не работает)

Пишем код

Запускаем тест

То есть состояние “разваленного проекта” для ТДД более чем естественно.

Но даже если вы думаете иначе, у меня два возражения:

Если вы внимательно посмотрите на любой современный компилятор практически любого языка, то увидите, что единицей компиляции является не проект, а файл. Нет нужды пересобирать тот код, который не менялся, собирается только нужный для получения актуального состояния. То есть я написал тест, скомпилировал, собрался только этот тест. Более того, как правило тесты это отдельная цель компиляции, а проект к ним тем или иным способом линкуется. То есть я могу вообще не иметь исходниов проекта, чтобы писать к нему тесты. Так что единственным требованием для работы тестов в том же objc является нормальность самих тестов.

Если вы поменяли что-то в проекте и у вас развалились тесты, вам совершенно неважно, запускается только что написанный тест или нет. У вас есть более важные проблемы -- падает туева хуча тестов. Это форс-мажор, надо бросать все и чинить. А к работоспособности текущего теста можно и попозже вернуться.

Ну и последнее, возможность компиляции отдельных методов это, конечно, круто и удобно для написания тестов. Но учитывая наличие у некоторых из “некошерных” языков нормальных систем типизации (Scala, F#, OCaml, Haskell, etc), вопрос встает совершенно иным боком. Процентов 70 тестов, которые я вынужден писать для Objective-C (прямой потомок St) просто нет смысла писать на хаскеле. Там подобные вещи на этапе компиляции выясняются автоматически, без тестов.

От: [hidden email]
Отправлено: ‎четверг‎, ‎24‎ ‎октября‎ ‎2013‎ г. ‎23‎:‎18
Кому: [hidden email]

24 октября 2013 г., 20:30 пользователь <[hidden email]> написал:

Ну, я писал, что куча языков кроме Смолтока так умеет. Да и пообще сравнивать Си и Smalltalk довольно странно.

ТДД для того и придуман, чтобы тесты падали, когда что-то меняется, я не вижу особой проблемы в том, что вы описали, если честно 😊

Суть в том, что вы не запустите ваш тест пока вся ваша система не будет избавлена от ошибок компиляции, что убивает весь процесс TDD

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

semka.novikov

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

In reply to this post by Dennis Schetinin

Ну и мои представления о TDD вообще основаны на книжке Кента Бэка, который его придумал :) Кроме того, что я в него не верю.

Кстати, меня попросили сделать небольшой доклад для коллег на тему тестирования кода для iOS/OSX, там моя позиция выражена вполне ясно, если интересно, вот слайды: http://random-stuff.sdfgh153.ru/talks/ios-testing/ (Их много, небольшой это на 2 часа :)

Буду признателен за критику.

От: [hidden email]
Отправлено: ‎суббота‎, ‎26‎ ‎октября‎ ‎2013‎ г. ‎12‎:‎40
Кому: [hidden email]

Best regards,

Dennis Schetinin

25 октября 2013 г., 7:42 пользователь <[hidden email]> написал:

У нас с вами какие-то очень разные представления о ТДД, по-моему. А ещё тут некоторое непонимание устройства современных компиляторов есть.

ТДД это штука, которая гарантирует определенный (невысокий, кстати) уровень непротиворечивости кода в тот момент, когда тесты зелёные. Так же в её обязанности входит просигнализировать когда состояние становится противоречивым.

Когда проект не собирается -- это явно противоречивое состояние. И тесты обязаны падать. Вспомните, как Бек описывал ТДД:

Пишем тест, который использует несуществующий еще код

Программа не собирается (~ тест не работает)

Пишем код

Запускаем тест

То есть состояние “разваленного проекта” для ТДД более чем естественно.

Но даже если вы думаете иначе, у меня два возражения:

Если вы внимательно посмотрите на любой современный компилятор практически любого языка, то увидите, что единицей компиляции является не проект, а файл. Нет нужды пересобирать тот код, который не менялся, собирается только нужный для получения актуального состояния. То есть я написал тест, скомпилировал, собрался только этот тест. Более того, как правило тесты это отдельная цель компиляции, а проект к ним тем или иным способом линкуется. То есть я могу вообще не иметь исходниов проекта, чтобы писать к нему тесты. Так что единственным требованием для работы тестов в том же objc является нормальность самих тестов.

Если вы поменяли что-то в проекте и у вас развалились тесты, вам совершенно неважно, запускается только что написанный тест или нет. У вас есть более важные проблемы -- падает туева хуча тестов. Это форс-мажор, надо бросать все и чинить. А к работоспособности текущего теста можно и попозже вернуться.

Ну и последнее, возможность компиляции отдельных методов это, конечно, круто и удобно для написания тестов. Но учитывая наличие у некоторых из “некошерных” языков нормальных систем типизации (Scala, F#, OCaml, Haskell, etc), вопрос встает совершенно иным боком. Процентов 70 тестов, которые я вынужден писать для Objective-C (прямой потомок St) просто нет смысла писать на хаскеле. Там подобные вещи на этапе компиляции выясняются автоматически, без тестов.

От: [hidden email]
Отправлено: ‎четверг‎, ‎24‎ ‎октября‎ ‎2013‎ г. ‎23‎:‎18
Кому: [hidden email]

24 октября 2013 г., 20:30 пользователь <[hidden email]> написал:

Ну, я писал, что куча языков кроме Смолтока так умеет. Да и пообще сравнивать Си и Smalltalk довольно странно.

ТДД для того и придуман, чтобы тесты падали, когда что-то меняется, я не вижу особой проблемы в том, что вы описали, если честно 😊

Суть в том, что вы не запустите ваш тест пока вся ваша система не будет избавлена от ошибок компиляции, что убивает весь процесс TDD

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

Denis Kudriashov

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

In reply to this post by semka.novikov

25 октября 2013 г., 7:42 пользователь <[hidden email]> написал:

ТДД это штука, которая гарантирует определенный (невысокий, кстати) уровень непротиворечивости кода в тот момент, когда тесты зелёные. Так же в её обязанности входит просигнализировать когда состояние становится противоречивым.

Вы неправы. TDD - это подход к проектированию системы в коде. TDD не гарантирует непротиворечивости кода и не создано для этого.

Я так понимаю, вы здесь путаете TDD и отдельный этап в разработке "тестирование". TDD - это не тестирование.

Следуя TDD, вы описываете поведение разрабатываемой системы в виде тестов. Каждый тест - это спецификация отдельного аспекта работы системы. Зеленый тест или красный означают, соответствует ли ваша система данной спецификации или нет. Никаким образом это не связано с непротиворечивостью кода. Тесты могут быть красные, а программа прекрасно работать, просто программист "не поправил свои требования к системе". И тесты в такой ситуации просто сигнализируют, что свойства системы изменились.

Тем неменее, непротиворечивость кода может быть вашим требованием к системе, и тогда в соответствии с TDD вы опишите это требование, ваше понимание непротиворечивости, в тестах.

Когда проект не собирается -- это явно противоречивое состояние. И тесты обязаны падать. Вспомните, как Бек описывал ТДД:

Пишем тест, который использует несуществующий еще код

Программа не собирается (~ тест не работает)

Пишем код

Запускаем тест

То есть состояние “разваленного проекта” для ТДД более чем естественно.
Но даже если вы думаете иначе, у меня два возражения:

Если вы внимательно посмотрите на любой современный компилятор практически любого языка, то увидите, что единицей компиляции является не проект, а файл. Нет нужды пересобирать тот код, который не менялся, собирается только нужный для получения актуального состояния. То есть я написал тест, скомпилировал, собрался только этот тест. Более того, как правило тесты это отдельная цель компиляции, а проект к ним тем или иным способом линкуется. То есть я могу вообще не иметь исходниов проекта, чтобы писать к нему тесты.

Этот пункт меня вообще удивил. Какое отношение он имеет к реальности?

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

Так что единственным требованием для работы тестов в том же objc является нормальность самих тестов.

Если вы поменяли что-то в проекте и у вас развалились тесты, вам совершенно неважно, запускается только что написанный тест или нет. У вас есть более важные проблемы -- падает туева хуча тестов. Это форс-мажор, надо бросать все и чинить. А к работоспособности текущего теста можно и попозже вернуться.

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

В динамически типизированных языках такой проблемы просто нет. И как я уже говорил, ява с эклипсом здесь работает отлично.

Ну и последнее, возможность компиляции отдельных методов это, конечно, круто и удобно для написания тестов. Но учитывая наличие у некоторых из “некошерных” языков нормальных систем типизации (Scala, F#, OCaml, Haskell, etc), вопрос встает совершенно иным боком. Процентов 70 тестов, которые я вынужден писать для Objective-C (прямой потомок St) просто нет смысла писать на хаскеле. Там подобные вещи на этапе компиляции выясняются автоматически, без тестов.

А приведите пример теста, который вы бы не стали писать в хаскеле

semka.novikov

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

Именно это я и имею в виду под “непротиворечивостью”. Тем не менее ТДД не подразумевает продолжения работы если “красный” хотя бы один тест. По крайней мере так считает Бэк.

От: [hidden email]
Отправлено: суббота, 26 октября 2013 г. 13:53
Кому: [hidden email]

25 октября 2013 г., 7:42 пользователь <[hidden email]> написал:

ТДД это штука, которая гарантирует определенный (невысокий, кстати) уровень непротиворечивости кода в тот момент, когда тесты зелёные. Так же в её обязанности входит просигнализировать когда состояние становится противоречивым.

Я так понимаю, вы здесь путаете TDD и отдельный этап в разработке "тестирование". TDD - это не тестирование.

Когда проект не собирается -- это явно противоречивое состояние. И тесты обязаны падать. Вспомните, как Бек описывал ТДД:

Пишем тест, который использует несуществующий еще код

Программа не собирается (~ тест не работает)

Пишем код

Запускаем тест

То есть состояние “разваленного проекта” для ТДД более чем естественно.
Но даже если вы думаете иначе, у меня два возражения:

Если вы внимательно посмотрите на любой современный компилятор практически любого языка, то увидите, что единицей компиляции является не проект, а файл. Нет нужды пересобирать тот код, который не менялся, собирается только нужный для получения актуального состояния. То есть я написал тест, скомпилировал, собрался только этот тест. Более того, как правило тесты это отдельная цель компиляции, а проект к ним тем или иным способом линкуется. То есть я могу вообще не иметь исходниов проекта, чтобы писать к нему тесты.

Этот пункт меня вообще удивил. Какое отношение он имеет к реальности?

Так что единственным требованием для работы тестов в том же objc является нормальность самих тестов.

Если вы поменяли что-то в проекте и у вас развалились тесты, вам совершенно неважно, запускается только что написанный тест или нет. У вас есть более важные проблемы -- падает туева хуча тестов. Это форс-мажор, надо бросать все и чинить. А к работоспособности текущего теста можно и попозже вернуться.

Ну и последнее, возможность компиляции отдельных методов это, конечно, круто и удобно для написания тестов. Но учитывая наличие у некоторых из “некошерных” языков нормальных систем типизации (Scala, F#, OCaml, Haskell, etc), вопрос встает совершенно иным боком. Процентов 70 тестов, которые я вынужден писать для Objective-C (прямой потомок St) просто нет смысла писать на хаскеле. Там подобные вещи на этапе компиляции выясняются автоматически, без тестов.

А приведите пример теста, который вы бы не стали писать в хаскеле

Denis Kudriashov

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

In reply to this post by Denis Kudriashov

26 октября 2013 г., 13:53 пользователь Denis Kudriashov <[hidden email]> написал:

Тем неменее, непротиворечивость кода может быть вашим требованием к системе, и тогда в соответствии с TDD вы опишите это требование, ваше понимание непротиворечивости, в тестах.

Но согласитесь, звучит странно "непротиворечивость как требование к системе". И здесь у меня возникают вопросы:

Если программа работает и удовлетворяет всем бизнес-требований заказчика, означает ли это, что ее код непротиворечив? Я думаю в определенных границах да. (Я не претендую не на какую строгость, только практика).

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

Или еще, очень часто программа, действительно, работает хорошо и выглядит внешне отлично, но внутри одно сплошное спагети с томатным соусом. Может ли такая программа иметь непротиворечивый код? Из первого утверждения - да.

И здесь возникает вопрос о значимости свойства непротиворечивости кода. Если мои утверждения верны, то любая работающая программа до определенной степени (достаточной) непротиворечива. Но тогда какой практический смысл рассуждать об этом и превозносить языки, гарантирующие непротиворечивость математически?

Denis Kudriashov

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

In reply to this post by Dennis Schetinin

26 октября 2013 г., 12:40 пользователь Dennis Schetinin <[hidden email]> написал:

По крайней мере, в C++/C#/Java все обстоит именно так, разве нет? Правильная типизация как-то снимает эту проблему?

Сново повторюсь, эклипс такое позволяет. Технически он просто компилит проблемный код со вставками специальных эксепшинов, выводящий при вызове детали по ошибкам компиляции

Denis Kudriashov

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

In reply to this post by semka.novikov

26 октября 2013 г., 15:57 пользователь <[hidden email]> написал:

Именно это я и имею в виду под “непротиворечивостью”. Тем не менее ТДД не подразумевает продолжения работы если “красный” хотя бы один тест. По крайней мере так считает Бэк.

По ТДД мы не приступаем к новой фиче, пока есть красные тесты. Но мы говорим как раз о реализации новой фичи.

Допустим, сейчас у нас все тесты зеленые, пишем новый тест. В нем вызывается метод А, который внутри вызывает метод Б. Мы видим, тест падает на ассерте. Пытаемся поправить метод А, понимаем, что для этого нужно добавить в метод Б новый параметр. Изменяем метод Б, чтобы он принимал дополнительный параметр, а в методе А добавляем новый параметр к вызову метода Б. Теперь, нам кажется, что наш тест должен заработать.

Вдруг мы видим, так как сигнатуру метода Б меняли ручками (без рефакторинга), у нас больше не компиляться все тесты к методу Б и все методы системы (кроме А), в которых этот метод вызывается.

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

Несомненно, на данной итерации, мы все равно должны поправить все тесты. Но статическая компиляция при этом заставляет отвлекаться от текущей задачи, и заниматься несвязанными с ней вопросами. Это по сути нарушение принципа ТДД процесса "одна задача за раз", хотя это и происходит внутри одной итерации

semka.novikov

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

In reply to this post by Denis Kudriashov

Я, если честно, запутался в пострениях относительно непротиворечивости. Непротиворечивость программы это её способность безошибочно выполнять работу в рамках предметной области. Как правило это и есть требование заказчика.

Плюс ко всему, почему вы рассматриваете программу дискретно? “Вот, программа, работает”. Ни одна программа просто так не бывает “вот”. Она развивается, есть люди, которые её развивают. И чем больше внутри противоречий в логике, предметной модели, “хаков” и “хитрых трюков”, тем дороже становится программа в поддержке. Вот именно поэтому я и упираю на доказательство непротиворечивости, а вовсе не потому, что у меня так пятка левая хочет.

Я люблю аналогии, сейчас придумаю какую-нибудь. Ну, например, ремонт домов к приезду президента в уездном городе N. Знаете как его делают? Вешают красивый фасад. Смотришь на такой дом, он, вроде, удовлетворяет требованиям красоты. Но жить в нем всё равно сложно, когда течёт крыша и стены покрыты плесенью.

От: [hidden email]
Отправлено: суббота, 26 октября 2013 г. 14:18
Кому: [hidden email]

26 октября 2013 г., 13:53 пользователь Denis Kudriashov <[hidden email]> написал:

Тем неменее, непротиворечивость кода может быть вашим требованием к системе, и тогда в соответствии с TDD вы опишите это требование, ваше понимание непротиворечивости, в тестах.

Denis Kudriashov

Re: Кому нибудь интересна удалённая оплачиваемая работа над проектом с использованием Seaside?

26 октября 2013 г., 16:48 пользователь <[hidden email]> написал:

Я, если честно, запутался в пострениях относительно непротиворечивости. Непротиворечивость программы это её способность безошибочно выполнять работу в рамках предметной области. Как правило это и есть требование заказчика.

Плюс ко всему, почему вы рассматриваете программу дискретно? “Вот, программа, работает”. Ни одна программа просто так не бывает “вот”. Она развивается, есть люди, которые её развивают. И чем больше внутри противоречий в логике, предметной модели, “хаков” и “хитрых трюков”, тем дороже становится программа в поддержке. Вот именно поэтому я и упираю на доказательство непротиворечивости, а вовсе не потому, что у меня так пятка левая хочет.

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

Так какой смысл в доказательстве ее непротиворечивости? Как вы сами сказали вопрос здесь в поддержки и развитии системы.

Или вы считаете, что на языке типа хаскель нельзя написать запутанную программу?

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

12345