1) языки программирования «считающие» начало «стандартных» массивов с 1 -> выдавать 0 при поиске очень удобно (как и с массивом C#)
2) мы имеем возможность создать массив, нумеруя его, скажем с -3 до 5 -> -1 означает конкретный индекс, а не отсутствие рез-та.
Да, пока писал, в голову пришла мысль, что де, можно было задать в indexOf смещение массива (0 — первый элемент, 1- второй) вне зав-ти от его индексации. Скажем, для приведенного во втором примере массива indexOf == 0 означал бы всего лишь -3 индекс. Но в этом случае опять бы возникла путаница и новые открытия, что де, платформа .NET не возвращает индекс, а возвращает смещение относительно начала. И снова интриги, расследования…
Да, наверное, я поторопился так писать. И тут необходимо было бы описать, что работу c bb-тегами поддерживается многими «текстовыми» редакторами использующими фреймы\div.
Также, я думаю, все знают, что, сделав тот же contenteditable, мы получаем возможность использовать хоткеи -> следствие использование тегов b, i…
Я допустил ошибку, описав это как bb. Вы правы. Было бы верно описать, что тот же textarea не поддерживает те же хоткеи (такие как ctrl+b)
Мне кажется, что все же это небольшая статья не может описать ВСЕ в этом плане. Вопросы о совместимости, на данный момент времени для меня представляются слишком сложными, чтобы уместить в объем поста на хабре. Тут и книги, подчас, может быть мало.
Ваш способ действенен (ИМХО) только для не очень большого числа версий. А представьте, если таких ключей 10… 15? да, можно все повесить на ifах и подобном… а теперь перейдите на часть — ушли одни разработчики, пришли другие. сколько им придется разбираться в такой версионности?
Проблема «изменения в будущем» мне видится в том, что «сколько модулей будет написано на существующей архитектуре».
Сменить все вызовы в этих модулях? Окей, ctrl+f — справились.
Из-за нового поведения новых функций (пусть и выполняющих те же действия) может смениться поведение модулей… Сюда добавляем зависимости модулей друг от друга и получаем «стопор» нашего проекта на N дней в лучшем случае. + время на модульное и интеграционное тестирование…
Вопросы совместимости и ее изменения, на мой взгляд, одни из самых сложных при разработке более-менее сложных продуктов.
Очень не согласен. (может быть я и не прав) Если говорить в общем — Обратная совместимость — это тот конек на котором держатся проекты.
Например Windows ее winapi. Он местами очень не логичный, но если только отказаться от него в сторону нового и лучшего — с windows уйдут сотни тысяч пользователей. Точно такая же картина будет и с другими проектами.
Теперь возьмите JQuery. в своей «новой» версии разработчики отказались от поддержки старых браузеров. Да, это уменьшит код и все такое. Но НИКАКОЙ грамотный предприниматель не будет жертвовать миллисекундой загрузки за счет N рублей прибыли. Именно понимая этот факт параллельно новой ветки JQuery до определенного момента будет развиваться и поддерживаться обратная совместимость по предыдущей ветке.
Итог: обратная совместимость должна быть. Но нужно понимать до какой поры. Если царь умер, пора перестать его слушаться, но если он еще дышит — не надо революций. Он ведь хороший этот царь. Нужный
На самом деле, сам пребываю в «пассивном» поиске способов написания.
Единственный способ, который знаю, довольно простой:
Для каждой фигуры определяем вес. (скажем пешка = 1, слон = 3 и так далее.)
Первоначально определяем для каждой клетки ее вес. (здесь стоит сказать, что фигура на крае «карты» всегда менее ценна, чем фигура ближе к центру. Поэтому определяем в соответствие с этими правилами весы клеток на шахматном поле. )
Для некоторых фигур можно определить массив положений (например для пешек — чем ближе к противоположному концу поля -> тем лучше)
Также необходимо определить в виде весов случаи — наша фигура N под ударом противника, наша фигура N под защитой другой нашей фигуры, фигура N съедает фигуру M противника
Окей. С определениями закончили.
Следующий шаг простой — в существующий алгоритм добавляем проверку на ход AI.
Что будет делать AI — в его задачи входит:
1) оценка текущей ситуации на поле (по весам) -> сумма весов
2) Задаем AI брать по очереди каждую фигуру и делать возможный ход -> пересчет весов.
3) Выбор максимального веса.
Из дальнейших улучшений -> после каждой оценки возможного хода — оценка ответного хода человека -> выбор макс по двум оценкам (чем расчет идет «глубже», тем лучше играет AI)
теперь отступление от представленной краткой нотации алгоритма — писал шахматы в виде первой пробы в JS — тогда был ужаснейший код. Представленное в сообщении выше — это переписанный код. Но есть и пример кода (жаль, что он не совсем корректный, но ради интереса попробовать — можно тут
В вузах учат оформлять блок-схемы по ГОСТ'у. По крайней мере в моем… И использование в оной привязки к ЯП «жестоко карается».
А по реализации непосредственно уголков — очень иногда сложно понять, как шашка с одного места оказалась в другом — может быть последовательно каждый прыжок «прорисовывать»?
Вообще, мое маленькое мнение по всему этому поводу… сделайте НОРМАЛЬНЫЙ, УДОБНЫЙ сервис. Именно большими буквами. Не суть важно, будет он платным или построенным на рекламе. Если пользователи будут считать, что ценники адекватные (в соотношении услуги\цена), то многие уйдут с «пираток». Просто потому что:
1) Есть удобный сервис
2) Он лицензионный
3) Все необходимое можно получить как и по принципу пираток
Как удачный пример Ру сегмента могу привести яндекс.музыку.
Сервис весьма удобен, да и пополняется весьма быстро. Стал великолепной заменой пиратской музыки.
Если кто-то пишет ради ТОЛЬКО бабла, это сказывается на конечном варианте… Для души, для души, Господа. А там, глядишь, и монетки в кармане приятно зазвенят)
Согласен… На ПК висит куча книг, которые открывались и читались по правилу — стоит покупать или нет. В книжных магазинах, как правило, нет возможности взять книгу, полистать с полчасика (минимум), чтобы понять, нравится тебе оноя, или нет
С отечественным кино проще… Оно, зачастую, само себя губит…
А вот про писателей… Благодарный читатель купит книгу. Успех книги в интернете сподвигает пользователя купить в «щупательном» варианте книгу. Не замечал, чтобы успешные писатели жаловались на интернет…
Клиент сам настраивает списки сообщений хранимых и удаляемых с сервиса — службы, номера, диапазоны номеров и т.д. (номера объединяются в группы для которых создаются правила и тому подобное)
Все изменения с настройками отправляются клиенту. (уведомления об изменении настроек сервиса — чтобы при «захвате» акк злоумышленниками и перенастройкой сервиса клиент знал, что за ним «возможно следят»
Конечно, может у меня и паранойя, но дополнительная безопасность никому еще плохо не делала (ИМХО)
1) языки программирования «считающие» начало «стандартных» массивов с 1 -> выдавать 0 при поиске очень удобно (как и с массивом C#)
2) мы имеем возможность создать массив, нумеруя его, скажем с -3 до 5 -> -1 означает конкретный индекс, а не отсутствие рез-та.
Да, пока писал, в голову пришла мысль, что де, можно было задать в indexOf смещение массива (0 — первый элемент, 1- второй) вне зав-ти от его индексации. Скажем, для приведенного во втором примере массива indexOf == 0 означал бы всего лишь -3 индекс. Но в этом случае опять бы возникла путаница и новые открытия, что де, платформа .NET не возвращает индекс, а возвращает смещение относительно начала. И снова интриги, расследования…
Также, я думаю, все знают, что, сделав тот же contenteditable, мы получаем возможность использовать хоткеи -> следствие использование тегов b, i…
Я допустил ошибку, описав это как bb. Вы правы. Было бы верно описать, что тот же textarea не поддерживает те же хоткеи (такие как ctrl+b)
Ваш способ действенен (ИМХО) только для не очень большого числа версий. А представьте, если таких ключей 10… 15? да, можно все повесить на ifах и подобном… а теперь перейдите на часть — ушли одни разработчики, пришли другие. сколько им придется разбираться в такой версионности?
Сменить все вызовы в этих модулях? Окей, ctrl+f — справились.
Из-за нового поведения новых функций (пусть и выполняющих те же действия) может смениться поведение модулей… Сюда добавляем зависимости модулей друг от друга и получаем «стопор» нашего проекта на N дней в лучшем случае. + время на модульное и интеграционное тестирование…
Вопросы совместимости и ее изменения, на мой взгляд, одни из самых сложных при разработке более-менее сложных продуктов.
Например Windows ее winapi. Он местами очень не логичный, но если только отказаться от него в сторону нового и лучшего — с windows уйдут сотни тысяч пользователей. Точно такая же картина будет и с другими проектами.
Теперь возьмите JQuery. в своей «новой» версии разработчики отказались от поддержки старых браузеров. Да, это уменьшит код и все такое. Но НИКАКОЙ грамотный предприниматель не будет жертвовать миллисекундой загрузки за счет N рублей прибыли. Именно понимая этот факт параллельно новой ветки JQuery до определенного момента будет развиваться и поддерживаться обратная совместимость по предыдущей ветке.
Итог: обратная совместимость должна быть. Но нужно понимать до какой поры. Если царь умер, пора перестать его слушаться, но если он еще дышит — не надо революций. Он ведь хороший этот царь. Нужный
Единственный способ, который знаю, довольно простой:
Для каждой фигуры определяем вес. (скажем пешка = 1, слон = 3 и так далее.)
Первоначально определяем для каждой клетки ее вес. (здесь стоит сказать, что фигура на крае «карты» всегда менее ценна, чем фигура ближе к центру. Поэтому определяем в соответствие с этими правилами весы клеток на шахматном поле. )
Для некоторых фигур можно определить массив положений (например для пешек — чем ближе к противоположному концу поля -> тем лучше)
Также необходимо определить в виде весов случаи — наша фигура N под ударом противника, наша фигура N под защитой другой нашей фигуры, фигура N съедает фигуру M противника
Окей. С определениями закончили.
Следующий шаг простой — в существующий алгоритм добавляем проверку на ход AI.
Что будет делать AI — в его задачи входит:
1) оценка текущей ситуации на поле (по весам) -> сумма весов
2) Задаем AI брать по очереди каждую фигуру и делать возможный ход -> пересчет весов.
3) Выбор максимального веса.
Из дальнейших улучшений -> после каждой оценки возможного хода — оценка ответного хода человека -> выбор макс по двум оценкам (чем расчет идет «глубже», тем лучше играет AI)
теперь отступление от представленной краткой нотации алгоритма — писал шахматы в виде первой пробы в JS — тогда был ужаснейший код. Представленное в сообщении выше — это переписанный код. Но есть и пример кода (жаль, что он не совсем корректный, но ради интереса попробовать — можно тут
А по реализации непосредственно уголков — очень иногда сложно понять, как шашка с одного места оказалась в другом — может быть последовательно каждый прыжок «прорисовывать»?
код на codepen
Попробовать для удобства
Если интересна «пошаговая инструкция» готов описать «путь создания»
Если у кого-то есть хороший материал по написанию шахматных ботов, поделитесь, буду очень благодарен.
1) Есть удобный сервис
2) Он лицензионный
3) Все необходимое можно получить как и по принципу пираток
Как удачный пример Ру сегмента могу привести яндекс.музыку.
Сервис весьма удобен, да и пополняется весьма быстро. Стал великолепной заменой пиратской музыки.
А вот про писателей… Благодарный читатель купит книгу. Успех книги в интернете сподвигает пользователя купить в «щупательном» варианте книгу. Не замечал, чтобы успешные писатели жаловались на интернет…
В итоге в статье есть только описание prototype и то в очень «легком» виде без объяснения и разъяснения…
Статья не имеет, на мой взгляд, никакой изюминки.
Дочитал статью, понял, что это больше из категории «и такое бывает»
Конечно, может у меня и паранойя, но дополнительная безопасность никому еще плохо не делала (ИМХО)