По старому коду согласен на все 100. По новому тоже. У меня лично мало уважения вызывает продукт, особенно если он стоит хоть копейку, который был недавно написан и его разработчик не задумался о кроссплатформенности.
да ладно ребят, может не та те хабы подписаны? Я только с хабра узнал про qt, и много чего десктопного.
Очень жаль что остаются разработчики которые думают только об одно ОС. Пользуясь OS X уже несколько лет я не вижу себя за ОС Windows. При этом есть огромное количество приложений которые мне не обходимы но разрабы считают что раз у них Windows, значит и клиенты под windows должны быть. Выручает wine но не всегда.
И я откровенно не понимаю почему нельзя заморочиться и делать приложения более кроссплатформенными? Нет нормального фреймворка? Блин может потому что у разрабов нет потребности или желания? Нет спроса нет предложения. Хотя меня лично бесплатный Qt Studio всем устроил. И потратив 4 часа компьютерного времени на компиляцию окружения я прекрасно написал себе dll из под мака для моих нужд.
Переживаете что никто не пишет статьи про windows разработку? Welcome! Я лично прочитаю, плюсану и поблагодарю увидев такую статью.
Для меня хабр не то место где люди постоянно критикуют и ноют. (простите но это нытье) Для меня это место где любой энтузиаст может имея лишь желание написать хороший и полезный материал, задать любой технический вопрос, и получить зачастую очень квалифицированный ответ.
Так что нет статей про windows разработку, начните их писать! Я обязательно подпишусь и буду читать. Для меня эта тема далекая но очень интересная.
tcp гарантирует очередность доставки сообщений. Это дает очень интересный эффект на IP телефонии например. Но тут на этот эффект можно смело положиться
А вообще интрересно как будет реализована многопоточность или асинхронность. Сейчас, если я правильно понимаю, сервер может принять лишь одно подключение.
Вопрос: Почему не сделать через датаграммы, концом которых будет например двойной возврат каретки. Так мы можем делить полученные данные на команды. И не надо считать сколько данных мы передаем. Мне почему-то показался такой вариант красивее.
Тоже хотел написать что тут вина программистов если и есть то минимальна.
В статье говорится о том что программистов могут за ошибку выгнать из профессии и вообще какой-то странный упор делается на программистов.
1. Если уж на чистоту, программный код управляет железом, которое так же судя по всему было заточено на данный функционал.
2. Чем в данном случае программист отличается от инженера разрабатывающего системы впрыска, строение двигателя и тд? ( не силен в области снижения CO в выхлопных газах ДВС)
3. Если этот «баг» смогли обнаружить не программисты, значит у компании мало человекочасов было уделено тестированию и подготовке к выходу авто. Или все это было сделано по тз и тесты прошли успешно. Но это тз не только для программистов, это тз было для всех кто участвовал в разработке авто, включая тестировщиков.
# Принимаем переданных клиентом данные, но не более 1024 байт
data = conn.recv(1024)
Скорее принимаем первые 1024 байта. Это работа с сырыми сокетами и команда, как я понимаю является прямым биндингом к recv в C.
Думаю в python есть более высокоуровневые решения.
Поправьте, если ошибаюсь.
Возможно я не прав, но Хабр все ж не для рекламы да еще и такой неприкрытой. Если хотите рассказать о своем продукте, расскажите с технической точки зрения. Если хотите рассказать интересную новость, не надо пихать рекламу.
Лично мне интересно было бы прочитать статью и комментарии к Вашему продукту. Но не в новости про то чем руководствуются хакеры
К моему стыду ни разу не слышал про расстояние Левенштейна. Было приятно узнать что-то новое. А Вам — успехов в нелегком труде. И советую использовать какой-нибудь framework, возможно развитие пойдет легче, а у студентов будет чуть меньше шансов на нечестную работу с приложением.
Вот мне тоже стало интересно. А если найдут уязвимости в jpg, png, html я уж не знаю, mp3. Мы их тоже сможем получать только подписанными?) Интересно будет выглядеть все фотки в контактике надо будет открывать только если вы доверяете их издателю))
Наверное один плюс этой статьи все же есть. В ней упоминаются действительно вещи которые желательно бы знать человеку, связанному с IT. Есть отсылки на wiki и другие материалы. Думаю человеку, имеющему пытливый ум, будет интересно почитать про те технологии которые, возможно он не изучал ранее. А выводы из любого материала мы должны делать сами, и говорить о том что так уж ужасно что кто-то прочитает статью и станет плохим специалистом, не верно. Если человек сделает выводы основываясь на одной статье, он уже плохой специалист.
Очень жаль что остаются разработчики которые думают только об одно ОС. Пользуясь OS X уже несколько лет я не вижу себя за ОС Windows. При этом есть огромное количество приложений которые мне не обходимы но разрабы считают что раз у них Windows, значит и клиенты под windows должны быть. Выручает wine но не всегда.
И я откровенно не понимаю почему нельзя заморочиться и делать приложения более кроссплатформенными? Нет нормального фреймворка? Блин может потому что у разрабов нет потребности или желания? Нет спроса нет предложения. Хотя меня лично бесплатный Qt Studio всем устроил. И потратив 4 часа компьютерного времени на компиляцию окружения я прекрасно написал себе dll из под мака для моих нужд.
Переживаете что никто не пишет статьи про windows разработку? Welcome! Я лично прочитаю, плюсану и поблагодарю увидев такую статью.
Для меня хабр не то место где люди постоянно критикуют и ноют. (простите но это нытье) Для меня это место где любой энтузиаст может имея лишь желание написать хороший и полезный материал, задать любой технический вопрос, и получить зачастую очень квалифицированный ответ.
Так что нет статей про windows разработку, начните их писать! Я обязательно подпишусь и буду читать. Для меня эта тема далекая но очень интересная.
Мне кажется в tcp с UDP немного путаете.
В статье говорится о том что программистов могут за ошибку выгнать из профессии и вообще какой-то странный упор делается на программистов.
1. Если уж на чистоту, программный код управляет железом, которое так же судя по всему было заточено на данный функционал.
2. Чем в данном случае программист отличается от инженера разрабатывающего системы впрыска, строение двигателя и тд? ( не силен в области снижения CO в выхлопных газах ДВС)
3. Если этот «баг» смогли обнаружить не программисты, значит у компании мало человекочасов было уделено тестированию и подготовке к выходу авто. Или все это было сделано по тз и тесты прошли успешно. Но это тз не только для программистов, это тз было для всех кто участвовал в разработке авто, включая тестировщиков.
Скорее принимаем первые 1024 байта. Это работа с сырыми сокетами и команда, как я понимаю является прямым биндингом к recv в C.
Думаю в python есть более высокоуровневые решения.
Поправьте, если ошибаюсь.
Лично мне интересно было бы прочитать статью и комментарии к Вашему продукту. Но не в новости про то чем руководствуются хакеры