Pull to refresh
1
0
Федоров Руслан @aspcartman

User

Send message
posix_spawn режется. Имхо режутся все системные вызовы по номерам. Еще варианты?

Да ладно, не жалуют, самые одаренные малвар-кодеры потом и пишут весь фундамент, на котором все работает. Ну, если в плохих мальчиков надоест играть. :3
Пропускает или нет не важно
а) Enterprise Program не имеет стадии ревью
б) Все, что не пропускает ревью, можно зарелизить с помощью Dark Release.
Добравшись до гугла обнаружилось, что iOS блокирует вызов fork(). http://stackoverflow.com/questions/12088155/fork-failed-1-operation-not-permitted
А жаль. Интересно, чего бы еще такого придумать в обход Вашего способа…
Enterprise program? Я лишь слышал, что там нет проверок эпл, и если это так, то решением будет fork() и совершение слежки в дочернем процессе.
1. Регистрируем обработчики сигналов, внимательно смотрим, как система вас убивает и будет ли она трогать вас вообще. Я полагаю, что она будет убивать только процесс самого приложения, а сына оставит в покое.
2. Если все замечательно и вас даже не убивают, то можно подобрать какуюнибудь точку рандеву, с помощью shmem, pipe или чего бы то ни было еще, что бы проверить, а нужно ли делать форк или сынок уже в работе.

Это комментарий-предположение. Я полагаю, что никаких препятствий для такой реализации нет, но в этом не уверен.
Ну тогда, получается, мы наблюдаем схему, описанную в конце моего коментария. «Сделал — выбросил».
Сам работаю в другой сфере, над проектами работы ведутся долго, и после каждого релиза проводятся циклы рефакторинга и багфиксинга по необходимости. Мы свой код и продукты любим. Я бы точно не смог работать эффективным веб разработчиком).
Нельзя охватить все случаи. У меня есть проект на Go, и если я буду искать на его поддержку другого разработчика, я буду руководствоваться общими принципами, просто потому, что найти Go-разработчика достаточно трудоемко, а полноценно зашарить этот язык можно, по моей субьективной оценке, можно за дни-неделю. Тут случай сложной задачи и простого инструмента -> искать хорошего программиста (гонять по алгоритмам и general вопросам, возможно специфичным для сферы, тут это будет многопоточность и бэкенд разработка), пусть и не знакомого с инструментом.

Учитывая, что вы устраиваете работодателя в качестве С++ разработчика, имея за спиной пару лабораторных работ (и вспоминая обьем документа-спецификации языка С++, превышающий более чем в 10 раз онный для Си), то перед вами ставится как разработчиком ставится относительно простая задача с точки зрения С++ разработки, не требующая глубоких знаний инструмента (пока речь была только про язык, возможно Вы используете еще, например, boost, или qt). Простая задача, сложный инструмент -> (я) буду искать просто адекватного разработчика (простые алгоритмические задачи и простой-средней сложности общие вопросы) и немного знакомого с инструментом.

Однако, возвращаясь к iOS разработке, я говорил о сложной задаче (большое приложение с активным использованием advanced инструментов и сторонних популярных проектов) и сложном инструменте. Девелоперов — пруд прудей. И даже очень хороший Java\С++\Whatever разработчик, потратит очень уж много времени на то, чтобы на достаточном уровне въехать в тему. Я просто об этом не оговорился, my bad, но будь задача простая (маленькое тривиальное приложение), то я бы и не спрашивал про все эти инструменты, я думаю это логично. Так вот, тут сложная задача, сложный инструмент -> гоняем по инструментам в первую очередь, общие знание второчны и быстрее усваиваются, чем инструменты.
Быдлокод — результат недальновидности и не достаточной компетентности донести возможные последствия до людей о них не ведующих. Быдлокодить молча — себя же зарывать в яму и срывать сроки, постфактум, не сорвав срок текущий. Плюс некачественный результат — «оно вроде и работает, но через раз и как-то не так». Наверное, речь об этом. Есть вариант набыдлокодить для удержания текущего срока, и провести рефакторинг постфактум в период оговорки новых фич или другого, оговоренного и заплонированного зарание времени.

Просто быдлокодить — это не прагматизм, супротив наивности, а непрофессионализм. Единственный в моей практике случай, когда молчаливый быдлокод — хороший подход, это решения на один раз: скрипт какой, что-то сделать раз или два, или дата-анализ, посчитал что-то, получил результат и выкинул код.
Не везде, в имплементации, кажется, vfs (давно дело было, могу что-то путать), от goto глаза болели, прыжки были туда-обратно-поперек, а не обычные к выходу. Да и был случай, когда десяток-другой минут втыкал в аналогичную «прыжковую» функцию, пытаясь понять, как переменная оказывается не инициализированной.
Я считаю, что задавать стоит вопросы по инструментам и сторонним проектам, которые используются на искомой позиции. Ищем iOS разработчика — так и гоняем его по хитростям UIKit, Autolayout, Core-Data и популярным сторонним проектам. Смотрим уровень его понимания, сколько человек вынес из своего опыта. Если ищется девелопер — так и стоит с него спрашивать то, что от него будет требоваться на рабочем месте. Вопросы вроде «как сделать мердж» или какой-либо другой алгоритм, you name it, стоит спрашивать у джуниора.
Я согласен с тем, что функции E.BS и E.DS совершенно не читабельны и не ясны.

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

Повторюсь, дело в уровне.
Если бы эта часть проекта была написана на языке, поддерживающем исключения, то на месте E.DS и ко не было ничего, а на месте E.BS какой-нибудь Assert\Throw. И никаких try catch тоже не было здесь. Тут мы просто падаем вверх по колстэку после любого малейшего чиха, и покуда этот чих не будет распечатан в лог, нас совершенно не волнует, что это вообще такое было. Т.е ни одна из брошенных таким образом ошибок никогда не будет обработана каким-либо образом, отличным от «распечатать лог, сбросить транзакцию, кинуть 500».

Теперь представьте код обработчиков запросов серверного приложения. 40 возможных запросов API, 40 обработчиков, в каждом примерно 15 полезных (не обработка исключительных ситуаций) строчек кода, половина из которых может «ошибиться». Т.е каждой нужно воткнуть if err, каждой функции два возвращаемых значения, еще думать про различные типы ошибок и их как-то обрабатывать и бороться с синтаксисом языка, не подразумевающим возможности просто вернуть ошибку (второе возвращаемое значение) без указания первого, кроме как сделать его указателем (return nil,… ) или использовать именнованные возвращаемые значения.

Это — ад, товарищи. Error — инструмент, предназначенный совершенно не для этой работы.

Я хочу видеть в этом конкретном случае вот такой код
func registerNewUserHandler(nickname string) User {
	checkAvailability(nickname)
	user := addNewUserToDB(nickname)

	addLuckyBonusPoints(user)
	notifyEverybodyAboutNewcomer(user)

	scratchThePonies()
	return user
} 


и просто помнить, что любая строчка может вывалиться, а не вот такой:

func registerNewUser(nickname string) User, error {
	if !isAvailable(nickname) {
		return User{}, /* Whatever error style you guys prefer */
	}
	user, err := addNewUserToDB(nickname)
	if err != nil {
		return User{}, err
	}
	err = addLuckyBonusPoints(user)
	if err != nil {
		return User{}, err
	}
	err = notifyEverybodyAboutNewcomer(user)
	if err != nil {
		return User{}, err
	}

	err = scratchThePonies()
	if err != nil {
		return User{}, err
	}
	return user, nil
} 


Просто потому, что обработка ошибок тут — шум и не несет никакой полезной нагрузки. А потом оно еще уходит вверх и так же плодит в коде, вызывающем эту функцию, условные переходы. И зачем?
Я завожу новый тип, удовлетворяющий интерфейсу, обычно. Код выше — пример =).

Где-то через месяц я напишу несколько статей на тему того, к каким здравым и не очень решениям привела меня моя лень в сфере Go и Obj-C. Там же и все опишу. Исходников на гитхабе пока нет.
ИМХО:
Низкий уровень визжит от радости системой ошибок в Go. Очень удобно.
Прикладной уровень, где каждая ошибка это просто падение всего приложение\его части — люто его ненавидит.

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

// До
func SendMessage(db *gorm.DB, user S.User, rid uint, text string) (*S.Message, error) {
	if !user.registered {
		return nil, fmt.Errorf("User is not registered")
	}
	if !user.canSendMessages {
		return nil, fmt.Errorf("User can't send messages")
	}

	message := S.Message{}
	db.Create(S.Message{ ... })
	if db.Error() != nil {
		....
	}
	return &message
}

// После
func SendMessage(db *gorm.DB, user S.User, rid uint, text string) S.Message {
	E.BS(!user.registered, "User is not registered")
	E.BS(!user.canSendMessages, "User can't send messages")
	
	message := S.Message{}
	E.DS(db.Create(S.Message{ ... }), "Couldn't send message")
	return message
}


Внутри E.BS и E.DS происходит проверка на буль\ошибку в db, кидание паники вместе с именем файла, номером строки и переданной строчкой-описанием.

Выше это ловит обработчик транзакций и откатывает всю транзакцию к бд, а потом выше ловит роутер и пишет 500 в ответ на запрос. Соответственно есть и E.Throw, E.Catch и E.Rethrow. Работают паники в Go достаточно медленно, чтобы это можно было заметить, но я готов пожертвовать этим временем ради того, чтобы не писать такие нечитабельные кусты из условных переходов и return nil, err (а если первое возвращаемое значение — не указатель? мммм)
Нет, это я понимаю, в институте его рассматривали, однако же совершенно так же HDCP уязвим к Anal(og)-Hole attack: камеру напротив телевизора поставить никто не запретить.

А тут то даже камера не нужна. о_О
Вопрос про print_screen задавался коментатором выше, но все же хотелось бы поднять его еще раз. Как конкрентно можно не дать сделать скриншот? То, что MS может не дать делать скриншоты клавишей print screen в этих областях, apple не дать cmd+shift+3/4-ыть, линукс… линукс… как-то «линукс» и «не дать» в одном предложении не вяжется.
И что с того? Что мешает сделать скриншот любыми другими методами, да хотябы отрендерить куданибудь и снять слепок? Мне правда интересно.
Да, это конечно так :)
Я писал о том, что горутину никто не остановит. В вашем примере ее так же никто не остановил. :) Вы просто запустили две горутины. То, что рядом может выполняться еще горутина и одновременно с нами использовать наши же ресурсы, мне казалось очевидным, о чем я и написал:
> Очевидно, что рядом работают в других тредах другие горутины и они могут начать писать туда, куда пишем мы.

> Вот тогда мы и получаем возможные проблемы с одновременной записью в map, например, если не учтем этого.
Я просто не представляю, как можно не учесть этого. Невнимательность? Да, но а как же иначе? Если язык будет это за нас учитывать (не методами разделения ресурсов аля Rust, а блокировками) то мы, возможно, получим потери в скорости, где нам бы этого не хотелось.
Есть.
«Планировщик, я закончил на пока, дай другим поработать в моей треде» горутина говорит либо явно (есть спец функция), либо делая блокирующую операцию (чтение из канала). Примечательно, что если совершается системный вызов, то горутина зависает вместе со всей тредой и планировщик вынужден либо ждать, либо родить еще одну треду. Такие пироги.
Очевидно, что рядом работают в других тредах другие горутины и они могут начать писать туда, куда пишем мы. Но единственный язык, где об этом не нужно думать, это Rust.
Dark release. Спорные фишки, вызывающие вопросы у команды проверки, скрываем в приложении. После релиза сигналим с сервера, что опасность миновала, и включаем все.

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

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

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

Однако помню статью на хабре, где утверждалось обратное.

А еще есть ускоренное ревью…
Да пошли они с этими проверками в задницу, делайте молча дарк релиз и все. Все, что просят убрать — убираете в дарк релиз. Не раз решало проблему.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity