LINUX.ORG.RU

Погоня за жуками

 , ,


0

1

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

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

  • клиент - это устройство, а не пользователь, таким образом если у вас есть ноутбук и смартфон, то вы можете, например фотографию со своего смартфона перекинуть на свой ноутбук (без посредничества какого либо сервера).
  • пользователь и клиент идентифицируются своими публичными ключами
  • передача происходит по «подходящей» локальной сети, при этом несмотря на независимость от сервера планируется и сервер (для тех у кого nat, и чтобы определять адреса устройств)

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

на фото дебьян тестинг x2, intellij idea x2, самсунг + cyanogen и еще всяческая обстановка

ps. «Ответ на главный вопрос жизни, вселенной и всего такого»:

  • потому что на старой работе я потерял некоторые навыки и мне надо восстановиться
  • работодатели оценивают по анкетам - по ним я также проваливаюсь, и у меня нет моего кода который бы я мог показать
  • существующие способы обмена данными между «своими» устройствами меня печалят, особенно когда надо быстро передать ссылку, кусок текста или фото

>>> Просмотр (2076x1554, 1091 Kb)

Deleted

Проверено: JB ()
Последнее исправление: Deleted (всего исправлений: 2)

Что происходит на верхней панели декстопа? Там какие-то белые прямоугольники в левой и правой частях.

Идея звучит здорово, жду ебилдов работоспособной версии.

Weres ★★★
()
Ответ на: комментарий от JN
onClick
if (user != null)

А, теперь понятно. Вопросов нет.

JN
()

пожалуй, лучшая чашка в мире.

riso
()
Ответ на: комментарий от Deleted

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

ist76 ★★★★★
()

А король-то голый!
А код-то страшный! Что используешь для аутентификации публичными ключами?

f1xmAn ★★★★★
()
Ответ на: комментарий от f1xmAn

А код-то страшный!

что тебя испугало в нем?

Что используешь для аутентификации публичными ключами?

«некорректный вопрос»™, тебя используемые библиотеки криптографии интересуют, алгоритмы или что еще?

Deleted
()
Ответ на: комментарий от ist76

Вот поэтому у него его и не хватает...

sin_a ★★★★★
()
Ответ на: комментарий от Deleted

что тебя испугало в нем?

Сущности юзера и клиента (в чем отличие, может быть лучше назвать как-то более четко?), нечитаемый верхний if (вынеси условие в метод, название которого даст четкое представление о том, какое условие проверяется), сомнительная необходимость в final переменных в теле метода (без final ты бы смог инициализировать их null в той же строке, а не плодить else блок, а мог бы оставить переменные final, но вынести создание нужного инстанса в отдельный метод и не засирать код по сути ненужной информацией, что предпочтительнее), создание Configuration с анонимным классом прямо в setOnClickListener, везде доступ к полям через this, хотя без него код был бы более лаконичным, отступ вверху (метод вместо одной маленькой задачи выполняет несколько разных, поэтому тебе пришлось отделить 2 куска кода? Разбей на несколько методов), да и вообще метод выходит за рамки приличия из-за такой огромной не лаконичной простыни. Ну, это на первый взгляд.

тебя используемые библиотеки криптографии интересуют, алгоритмы или что еще?

Либы, которые сверяют публичный и приватный ключи.

f1xmAn ★★★★★
()
Ответ на: комментарий от f1xmAn

Сущности юзера и клиента (в чем отличие, может быть лучше назвать как-то более четко?)

там на эту тему документация есть

сомнительная необходимость в final переменных в теле метода

ты на яве то давно писал, как оно позволяет не финальные переменные в анонимном классе юзать?

создание Configuration

это не то что ты подумал https://github.com/wayerr/talkeeg/blob/master/android-client/src/main/java/ta...

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

бгг, но более подверженным ошибкам

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

да да он выполняет много задач: создает view для элемента списка.

Deleted
()
Ответ на: комментарий от Deleted

там на эту тему документация есть

Сразу стало легче. Можно было бы, в принципе, и переменные называть b243, ias08, а их предназначение описать в документации, но ты же так не делаешь.

ты на яве то давно писал, как оно позволяет не финальные переменные в анонимном классе юзать?

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

это не то что ты подумал

Я бы таки убрал оттуда анонимный класс.

бгг, но более подверженным ошибкам

Анахронизм. Современные программисты пишут код в среде разработки с подсветкой синтаксиса, как и ты, а не в блокноте, то, что это поле класса понятно и без лишнего this. Особенно с учетом того, что в методе нету ничего с похожими названиями, а без всякого мусора метод можно будет намного более коротким и читаемым.

отступ вверху

http://www.yegor256.com/2014/11/03/empty-line-code-smell.html
Тут изложено более подробно то, что я хочу донести.

f1xmAn ★★★★★
()
Ответ на: комментарий от f1xmAn

Сразу стало легче.

это хорошо, а то я надеялся что тебе понятно что такое оговоренный в рамках системы «термин»

Ты мог бы воспользоваться конструктором и заинжектить переменные через него.

мог бы, но шо так шо так нужен класс, только в твоем варианте там еще будет тонна кода (конструктор, поля и т.п.) и все ради одного метода в две строки, не вижу смысла

то, что это поле класса понятно и без лишнего this.

теперь внимание вопрос если ты откроешь код в ide где то не понятно? если ты заведешь переменную с такимже именем? по хорошему в java вообще не должно быть возможности обращаться к полям класса без this, также как это сделано в python

Тут изложено более подробно то, что я хочу донести.

там изложена мысль капитана очевидность, если эту мысль использовать фанатично, как ты предлагаешь то в моем коде надо:

* создать ClientListItemFactory

* в отдельном методе инициализировать поля ClientListItemFactory всеми визуальными компоненты из того где они сейчас в один класс (ну есесно описать его для начала)

* в ClientListItemFactory.build проинициализировать компоненты соответствующими значениями из списка клиентов

* в getView вызвать все вышеописанное

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

Deleted
()
Ответ на: комментарий от Deleted

это хорошо, а то я надеялся что тебе понятно что такое оговоренный в рамках системы «термин»

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

мог бы, но шо так шо так нужен класс, только в твоем варианте там еще будет тонна кода (конструктор, поля и т.п.) и все ради одного метода в две строки, не вижу смысла

Смысл в том, чтобы убрать эту кашу из твоего метода и сделать его более легко читаемым и поддерживаемым.

конструктор, поля и т.п.

Конструктор, поля, строка с названием класса — не такая уж и большая жертва в пользу читаемости.

теперь внимание вопрос если ты откроешь код в ide где то не понятно?

В смысле? Если я открою код в IDE, в которой из подстветки кода или по другим признакам нельзя понять, что это поле? Нужна ли такая IDE, да и сам программист, который не может выбрать лучший инструмент для своей работы?

если ты заведешь переменную с такимже именем?

usersService? В методе? Вряд ли.

по хорошему в java вообще не должно быть возможности обращаться к полям класса без this

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

с точки зрения «правильного проектирования» это будет кошерный подход

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

f1xmAn ★★★★★
()
Ответ на: комментарий от MyTrooName

как ты на таком маленьком столике помещаешься?

Он же белка. Белки могут.

kernelpanic ★★★★★
()
Ответ на: комментарий от f1xmAn

но здравый смысл подсказывает мне

похоже он не здравый

Смысл в том, чтобы убрать эту кашу из твоего метода

Конструктор, поля, строка с названием класса — не такая уж и большая жертва в пользу читаемости.

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

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

и предлагаешь десяток других правил.

у меня накопился опыт общения со студентами которые приходят со своим «аргументированным» стилем, со старперами которые «я так привык» и т.п. и с кодом который они рожают

поэтому правила такие: код должен быть минимально подвержен случайным ошибкам,

сидеть и три часа искать в каком месте поле отличается цветом от другого, где «случайно» обнулили переменную и т.п. мне лень

если в команде правят this-хейтеры, или желающие объявлять класс ради _одного_ использования то нет проблем - это вопрос не столь принципиальный, но это на работе.

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

ты лучше сам подумай еще раз - тебя не устраивает ни один вариант, но пустая вызывает ненависть

Deleted
()
Ответ на: комментарий от f1xmAn

там система немного другая, «хозяин» подписывает приватным ключом свою карточку с публичным ключом, т.е. по сути работает как простой сертификат

получатель вытаскивает публичный ключ и проверяет подпись сертификата, задача лишь достоверно (исключить MitM) передать публичный ключ

Deleted
()

Кстати, в плане приватного общения, есть Tox - может лучше подключиться к его развитию?

MEZON ★★★★★
()
Ответ на: комментарий от derlafff

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

- чем либо управлять не планируется

- оно должно работать на любой ос

- все устройства вяжутся к юзеру и передавать сообщения можно устройство-> устройство или устройство->юзер

Deleted
()
Ответ на: комментарий от MEZON

яндекс диск для передачи куска текста из буфера обмена?

Deleted
()
Ответ на: комментарий от MEZON

у меня же не мессенджер и приватности тут нет, только шифрование

Deleted
()
Ответ на: комментарий от Deleted

похоже он не здравый

Как ты можешь называть нездравой идею использования непересекающихся терминов в ubiquitous language? Вносить хаос и недопонимание, усложнять введение новых сотрудников в курс дела, это так прикольно, да?

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

Раздувание кода на 3 строчки, благодаря которым из метода выносится мусор, который усложняет его понимание и увеличивает область ответственности. Про nested классы не слышал?

и предлагаешь десяток других правил.

Это не правила, а предложения, которые улучшат читаемость в конкретно этом волосатом методе.

поэтому правила такие: код должен быть минимально подвержен случайным ошибкам

Если именно поэтому ты сознательно усложнил его читаемость, то тут какие-то проблемы в логике.

ты лучше сам подумай еще раз - тебя не устраивает ни один вариант, но пустая вызывает ненависть

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

P.S. А к студентам, кстати, лучше прислушиваться, потому что если они не правы, то ты сможешь объяснить им почему, и они больше не будут говнокодить в твоем проекте, а если правы, то преимущество от того, что ты их выслушаешь, очевидно. Свежий взгляд еще никому не вредил.

f1xmAn ★★★★★
()
Ответ на: комментарий от f1xmAn

усложнять введение новых сотрудников в курс дела

каких?

Раздувание кода на 3 строчки, благодаря которым из метода выносится мусор, который усложняет его понимание и увеличивает область ответственности

за шо я люблю теоретиков от программирования, так это за неправильный подсчет строк и неувядающее знамя «если я так считаю то это так и есть». твой любимый кусок и есть та самая область ответственности которую ты жаждешь «размазать» чтобы ее пришлось долго искать

предложения, которые улучшат читаемость ... ты сознательно усложнил его читаемость

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

я с гораздо большим удовольствием потрачу время на что-нибудь другое

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

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

ты определенно витаешь в облаках, единственный достоверный способ отучит студентов писать говнокод оказалось такое поведение:

рассказываешь как надо, он рассказывает как надо

он делает как себе решил

у него начинает глючить

рассказываешь как надо

он переписывает, глюк исчезает

Свежий взгляд еще никому не вредил.

еслиб ты сам себя слушался 8)

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Harald

ей >10 лет, и таки да я ее несколько раз разбирал для того чтобы она снова становилась белой

Deleted
()
Ответ на: комментарий от Deleted

ладно, два публичных ключа, приведённых к одинаковому однозначному представлению, например, DER

Harald ★★★★★
()
Ответ на: комментарий от f1xmAn

Можно было бы, в принципе, и переменные называть b243, ias08, а их предназначение описать в документации, но ты же так не делаешь.

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

fmdw
()

Kensignton трэкбол рулит, у меня такой же(два)

gorgoroth
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.