Pull to refresh
0
0
Ilya Okonsky @dslf

User

Send message
Прошу прощения, недописал:
> Явное приведение типов
Нет необходимости при правильном проектировании, приведенный Вами пример — плохой тон.

> TStringList
Приведенная Вами задача имеет более элегантное решение:
1) Через использование вспомогательного файла;
2) Считывание всего файла в контейнер/поток, вставка строки в начало контейнера/потока, перезапись файла/flush потока.

> Чтение данных с электронной почты
А класс, который напишет за Вас программу, Вы не хотите найти? Я не .Net программист, но уверен, что уже есть достаточное количество библиотек, реализующий данный функционал.

> Закладки в модулях кода
Они есть. Список всех шорткатов можно найти в документации к IDE, более того, можно самому выставить наиболее удобный шорткат.

> Поиск в модуле кода
Эта панель есть, Вы просто её не заметили. Более того, есть решарпер, о возможностях которого нет смысла здесь писать.

> Заключение
Язык программирования программисту следует выбирать исходя из задачи, которая перед ним стоит. Изучение ООП языка сводится к изучению его основной библиотеки/фрейворка, поэтому существенной разницы между ООП языками нет, есть небольшая разница между их фреймворками, те функции, которых нет можно найти в сторонних библиотеках. Хороший программист всегда будет писать хорошие программы, не важно на каком языке.

Спасибо, удачи в изучении языка.

> Проверка на попадание во множество
Не нужно, если правильно использовать контейнеры и парадигмы, которые предлагает сам язык.

> Вложенные функции
Нет необходимости. Если Вы в них нуждаетесь, значит Вы неправильно спроектировали класс/группу классов.

<зануда>
Ну и зачем в очередной раз разжевывать этот почти всем известный алгоритм?
Во всяком случае, это лучше чем писать посты о нвых айфонах.
</зануда>
Спешу заметить — дело здесь не в наличии/отсутсвии ТЗ, а в неправильной организации того самого общения, о котором Вы упомянули вначале.
> Уже тогда я четко понимал важность технологий общения в бизнесе.

За время, которое я работаю в сфере разработки ПО я понял одно: заказчик/начальник не знает чего он хочет, из него это надо вытягивать клещами. При этом все принятые решения следует записывать хотя бы в свободном виде. По сути, это называется совместное составление ТЗ. Кстати, очень важно убедить заказчика не скрывать информацию, которую он считает маловажной: лучше потратить некоторое время на фильтрацию информации от заказчика, чем проектировать и разрабатывать систему не представляя, как она будет использоваться и для чего она вообще нужна.
Ну, тут уже программист допустил ошибку в механизме синхронизации потоков, в любом случае, и то, и другое — ошибка программиста, за которую иногда хочется руки поотрывать.
Ну, можно еще отрывать руки разработчикам, которые выполняют длительные опреации (вычислительные или ввода-вывода) в потоке, в котором крутится GUI.
> Просто на осознание необходимости использовать инструменты учета времени у руководителей уходит очень много времени.

Кстати, есть один нюанс: все эти системы, методологии, и т.д. — все лишнее и все бесполезно пока руководитель смотрит на процесс разработки ПО как на автоматизированный конвеер. Уже чуть ли не на каждом столбе написано, что ПО создают люди, а не машины, и в управлении процессом разработки ПО надо отталкиваться от человеческого фактора. И даже при выборе инструментов, используемых при разработке следует это учитывать.
Скорее всего, меня заминусуют, однако все решается довольно просто: введением небольшого количества бюрократии в виде ежедневных отчетов для новых/неопытных сотрудников. В отчете должны содержаться пункты: какие задачи были поставлены, какие выполнены и за сколько времени, какие проблемы возникли, решились ли они и сколько на них ушло времени. Если текучка кадров небольшая, то у менеджера не будет отбирать много времени чтение отчетов.

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

На составление отчета времени уходит от 5 до 20 минут максимум. На его чтение и анализ — 10 — 30 минут. Профит просто огромен, если менеджер хоть как-то разбирается в людях и проекте, который он ведет.
В целом, концепция интерфейса приятна, однако он получился слишком сложным — не для изначальной целевой аудитории: как был в вашем первом макете недофотошоп, так им и остался.

Отличная идея в плане юзабилити — сделать тулбар в стиле контекстного меню.

Серьезные замечания по юзабилити и оформлению:
1) Не отрабатывается рисование/стирание по простому клику левой кнопки мыши — надо обязательно двигать мышь.

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

3) Про настройки параметров кисти отдельный разговор: если ползунок (Slider-control) имеет фиксированные значения — эти значения обязательно помечаются штрихами, например так:
----/ \--------
| | | |

4) Цветовая гамма, подобранная для контролов слишком тусклая, в неё приходится всматриваться т.к. на стандартном белом фоне плохо заметно активные элементы. Более того, нерабочие (disabled) элементы практически ничем не отличаются от рабочих. Ну а поскольку нельзя задать фон рисунка одни кликом, например, на черный — то этот пункт очень важен. Да и вообще, нужно больше яркости и насыщенности для интерфейса, он какой-то слишком сухой и строгий.

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

6) Еще раз про ползунки — они слишком маленькие, по ним ОЧЕНЬ трудно попасть мышкой;

7) И еще раз про ползунки — они ДОЛЖНЫ работать так, как работают стандартные контролы винды, к которым привык пользователь. Если ты зажал левую кнопку мыши на определенной позиции — ползунок ДОЛЖЕН на неё установиться со временем, без дополнительных кликов.

8) Подсвечивание активных элементов (Hotlight для кнопок) слишком слабое как для белого фона, в принципе, это можно отнести к пункту 4.

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

Спасибо, извините, если критика показалась слишком грубой. Продолжайте развивать проект, концепт хорош.
А те, кто разрабатывают инструменты — они создают то, чем им было бы самим приятно/удобно пользоваться.
Всегда считал, что холивары на тему трушности и ООП-ности какого из языков создаются теми, кто не занимается разработкой. Остальные же — просто выбирают наиболее им удобный или наиболее подходящий для проекта инструмент.
В начале ролика музыка мешает воспринимать слова, и это очень напрягает.
Не понравилось то, что для расширенного поиска сотрудников необходимо регистрироваться на сайте, либо это просто баг.
Еще постоянно сбивается закладка «Поиск сотрудников» на «Поиск ваканский» на странице поиска.

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

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

Так вот, хабра-сообщество, о чем я хочу глаголить. Бесспорно, некоторые из комментариев (да и сама статья) несут в себе разумное зерно. Но прочитав всё это, я не перестаю задавать себе вопрос «И что?». Каждый высказывает свою точку зрения, каждый выводит теории о том, «как бы нам обустроить нашу страну». Чем обсуждение этой статьи отличается от того, как сейчас работает наша законодательная и исполнительная власть? Все говорят «да, это правильно, надо сделать так-то и так-то». На этом всё и заканчивается.

Вот именно это мне и не нравится. Я уже успел поучаствовать в разговорах о том, что «молодежь не та», как со стороны «младшего», так и со стороны «старшего поколений». Разговоры эти все были одинаковы и по содержанию, и по последствиям. А последствия — все спокойно разошлись своей дорогой, никто ничего не предпринял, чтобы, как ему кажется, улучшить ситуацию.

В общем, я веду к тому, что все, что здесь говорится — это не бессмысленный треп, если хоть кто-то пойдет и что-то сделает. Ведь, по сути, основной контингент хабры — люди, которые и будут скоро строить будущее своей страны.
Присоединяюсь ко всем остальным по поводу той мысли, что не надо строить велосипеды, но спешу добавить, что порой, сделать велосипед — это единственный способ разобраться в чем-либо. Совет автору статьи — почитайте Рихтера «Windows via C/C++» и скачайте примеры кода к этой книге, там уже большинство всего необходимого реализовано.
> Спасибо, я так и делаю.
Спасибо, я так и
Раньше так и было, конечно :) Основная проблема — поиск этих самых маленьких компаний: в Интернете они редко дают объявления о вакансиях (и многие, из тех, кто дают обязательно хотят в/о и полный день, особенно в нынешнее время:) ), в газетах — еще реже. Если есть какие-то другие способы, кроме как по знакомству — я был бы рад о них узнать.
Не думаю, что в универской программе для технарей по психологии есть что-то серъезное, всего лишь основы, которые в большинстве своем и так понятны, без изучения предмета.

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity