• На чем писать кроссплатформенное GUI приложение?

    aparusov
    @aparusov
    Разработчик ПО, предприниматель
    Да, C++ на порядок сложнее по сравнению Java и С#, хотя Qt многое упрощает.

    Для кроссплатформенных офисных приложений хороша Java, - GUI на JavaFX или Swing, но не SWT (в нем много косяков, которые отнимают много времени). Если лучше знаешь C#, то на нем (язык посовременнее, фреймворк попроще будет) и сразу в MonoDevelop (так-как нужна кроссплатформенность).

    С серверной частью (если трехзвенка) важно определиться на чем она должна работать (в какой ОС). Если тоже кроссплатформенная, то лучше все на java делать и разобраться с серверными технологиями Java: Spring или Servlet-контейнер или даже сервер Java EE. Использовать ORM (Hibernate, например). Но с этим стеком Java придется повозиться, - порог вхождения высокий, зато потом открываются богатые возможности (независимые от ОС! ).
    Ответ написан
    Комментировать
  • На чем писать кроссплатформенное GUI приложение?

    sfi0zy
    @sfi0zy
    Creative frontend developer
    Для C# есть mono - свободный вариант .NET Framework (не то, чтобы во всем соответствовал ему, но работать можно). Работает, соответственно, и на Linux и на MacOS и на Windows. В местной IDE (MonoDevelop) можно создавать GUI в стиле drag&drop, как в старые времена на уроках информатики....

    От себя хочу добавить мысль о такой штуке как Vala. Если вы не слышали, это такой язык (я бы сказал смесь C-C#-Javascript), есть сравнение c C# для быстрого перехода на нее, удобная работа с GTK+ - окошки, кнопочки - все, что нужно делается просто и быстро, и, чтобы совсем не горевать, все это транслируется в чистый си. Соответственно собирается под любую платформу, где будет работать GTK+.
    Ответ написан
    2 комментария
  • На чем писать кроссплатформенное GUI приложение?

    @VZVZ
    Reverse-Engineer, Software Developer, Architect
    Сам по себе вопрос очень сомнителен.
    А нужно ли оно вообще на всех перечисленных системах?
    А почему везде должен работать один и тот же код? Может, достаточно сделать кроссплатформенной библиотеку, а GUI-оболочки написать под каждую ОС отдельно, на родных инструментах?

    > Что у java - не знаю.
    Очень сильно ЦП и ОЗУ грузит. GUI же у нее убог по виндовым меркам.

    > на сколько я понимаю, с GUI на не win платформах все очень плохо
    По меркам этих самых не win платформ - может и норм.
    Xamarin в первую очередь под Mac заточен. Я про Xamarin.Mac. Потому что "официальный" стек Xcode+Swift+Cocoa напрямую - это тоже не подарок, совсем не то, что Winforms на винде.
    Ну а на линуксе требования к гую вообще минимальны, такая уж это ОС.
    Так что вариант: под винду гуй на Winforms, под остальные - на чем-то Xamarinовском.
    Ответ написан
    3 комментария
  • На чем писать кроссплатформенное GUI приложение?

    @zelan
    Кратко обо мне не получится.
    Если Java - то JavaFX (только он). Выглядеть будет везде одинаково. Если писал гуи ни WPF, то с ним разберешься быстро (много очень похожих вещей - xml, binding, mvc). Стилизовать компоненты можно с помощью css, большое количество хороших контролов, в интернете есть библиотеки с кастомными контролами.

    Стартануть помогут:
    графический редактор форм javafx
    небольшой туториал (mvc, binding)
    Ответ написан
    Комментировать
  • Как уйти с распутья технологий?

    @0x131315
    Стратегию уже подсказали: найти любую работу, чтобы кушать, и тем самым выиграть время на изучение чего-то, что поможет зарабатывать больше, и тем самым выиграть еще больше времени, и в конце концов изучить то, благодаря чему будешь работать не на зарплату, а на удовлетворение.

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

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

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

    Конкретный язык нужен кодерам - это те, кто воплощает чужие идеи в коде, т.е. конечные винтики в процессе разработки софта, исполнители. От кодеров требуется только перенести уже готовый алгоритм на требуемый язык, максимально быстро, и по возможности без ошибок.
    Изучив конкретный язык ты можешь стать кодером, но это черновая работа, и по хорошему - временная, просто ступенька на пути становления программиста. Нужно двигаться к архитектору, инженеру, непосредственно программисту в широком смысле.

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

    Также упрощает задачу стандартизация подходов к решению задач, парадигм - большинство из них уже формализованы, и описаны. Например всем известное ООП, модульное программирование, конечные автоматы, и т.п. Описано более двух десятков таких моделей, их следует по возможности освоить. И не стесняться комбинировать.

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

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

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

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

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

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

    С третьим - придешь, когда поймешь, что тебе это нужно. Из-под палки не учатся.

    Со вторым все понятно: надо либо создать условия, либо отказаться от этой деятельности, и перейти к другой.
    Кто-то отказывается, уходит на другие работы, в основном физические, неквалифицированные, просто чтобы не думать. И как правило остается там до конца, уже не в силах выбраться из болота рутины.
    Кто-то приспосабливается - отгораживает себе уголок, меняет работу на ту, что дает больше свободного времени, начинает работать по ночам, забивает шум наушниками, и т.п. костыли.
    Кто-то кардинально меняет свою жизнь - переезжает в сьемные квартиры, выделяет себе комнату, изолирует ее или устанавливает в доме режим тишины, в общем создает себе полноценные комфортные условия для творчества. Это если удаленка - многие именно из-за невозможности работать дома, предпочитают офисы, или специальные кафе или клубы для работы.

    С первым все просто: не можешь что-то решить - отложи, и спустись на ступеньку ниже по шкале сложности.
    Есть такой психологический феномен: от решенных задач ты получаешь удовлетворение, силы и мотивацию двигаться вперед, от нерешенных - негатив, апатию, потерю воли и мотивации.
    Причем мозг устроен так, что запоминается лишь негатив. Поэтому крайне важно решать задачи, и не допускать незавершенных задач. Отложи, но не забрасывай.
    Нерешенная задача - это как психологический запой, нечто вроде депрессии: одна нерешенная задача тянет за собой другую нерешенную задачу, и так быстро уходишь на дно, теряя мотивацию и веру в себя. Замкнутый круг. Ты находишься именно в нем.

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

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

    Сложность задачи не особо влияет на мотивацию, а вот факт решения/нерешения - влияет сильно. Не решил - значит не осилил, не осилил - значит не достоин, не достоин - значит иди ко дну и не рыпайся. Это как импотенция: импотент - значит не мужик, не мужик - значит никто, ничего не достоин и об тебя можно ноги вытирать. Подсознание портит всю малину, так что не следует давать ему шанса - лучше решить задачу попроще, чем не решить по сложнее.
    Ответ написан
    7 комментариев
  • Структура Landing page?

    KubrickHabr
    @KubrickHabr
    вордпресс тим
    Первый блок должен состоять из продающего заголовка, описания товара/услуги и ctr кнопки для конверсии. Далее нужно тестить. Есть обязательные блоки первое что тебе нужно это закрыть боли клиентов, второе это показать преимущества работы с тобой, коротко рассказать о себе, Кейсы(портфолио), отзывы - чем авторитетней тем лучше,
    aaf94bc6239c4a16abcbd1da93937c6c.png
    Ответ написан
    1 комментарий
  • Как проверить работу подрядчика по контекстной рекламе?

    DeoZ
    @DeoZ
    Веб-разработка и Реклама
    Объём работы, конечно, предстоит немалый, если нужно проверить всё качественно и досконально.

    Пока ответы на первые Ваши вопросы:
    1. Да, из таких данных уже некоторую оценку сделать можно
    2. Нет, статистика в аналитических сервисах предоставляется за всё время начиная с установки счётчика. Исключение - поисковые фразы, подгружаемые в Google Analytics из Google Console, но это не ваш случай.
    3. Несмотря на отсутствие подключения кампаний к счётчикам какие-то данные аналитическими сервисами должны распознаваться изначально.

    Теперь вопросы к подрядчикам:
    1. Почему счётчики не были подключены к кампаниям и не были связаны аккаунты сразу при запуске рекламы. Это сразу минус подрядчику.
    2. Настроены ли цели в счётчиках для отслеживания конверсий. Если нет - значит подрядчику безразлично качество его трафика.
    3. Почему не предоставлены доступы в аккаунты Яндекс.Директ и Google Adwords по вашим кампаниям. Предоставить доступ - обычная практика. А здесь подозрение, что что-то скрывают.

    Теперь что следует в первую очередь сделать Вам:
    1. Зайдите в отчёты аналитических систем по источникам. Найдите там рекламные системы. Просмотрите показатели эффективности: отказы, время на сайте, средняя глубина просмотра. Если установлены цели - конверсия по целям.
      Сравните эти данные с другими источниками трафика. Я только могу привести примеры плохих показателей, чтобы было от чего отталкиваться, но они могут отличаться в зависимости от специфики сайта: отказы более 30%, время на сайте меньше минуты, глубина просмотра до 2 страниц.
    2. Сравните цифры по расходам рекламных кампаний из выгрузки с качеством такой кампании в счетчиках. Если на кампанию с не самой лучшей эффективностью тратится больше всего средств - это плохо. Часто подрядчики могут сливать бюджеты, например, на кампании РСЯ.
    3. Если есть выгрузка по запросам из систем, просмотрите насколько запросы высокочастотные (если пользовались SeoPult, знаете что это значит), насколько соответствуют вашей продукции. Нет ли слива бюджета только на небольшую группу высокочастотных запросов.

    Это Ваши первые действия, а так можно много чего смотреть и задавать множество вопросов подрядчику. По практике могу сказать, что идеальных кампаний не бывает.
    Ответ написан
    1 комментарий
  • Знак % в имени файла. Как сделать file_exist = true?

    alsopub
    @alsopub
    В вашем случае, видимо так:
    file_exists(str_replace('%', '#', $file))

    Но лично мне кажется, что на диске лежит не foto/32bb394c-2695-11e4-8fe3-005056ad2cf4#231.jpeg, а foto/32bb394c-2695-11e4-8fe3-005056ad2cf4#1.jpeg и правильный код будет:
    file_exists(urldecode($file))
    Ответ написан
    1 комментарий
  • Сколько исследователи тратят времени на поиск уязвимости и написание эксплойта подобного рода(в описании)?

    Не знаю, где вы читали эту новость, но по этим двум источникам выходит, что большую часть написанного в вопросе вы сами придумали, и все намного проще:
    gtlaunch.ru/hakeryi-iz-anonsec-ugnali-u-nasa-bespi...
    https://xakep.ru/2016/02/02/anonsec-nasa-leak/

    Итак, смотрим:
    Так как к трояну Gozi группа отношения не имеет, хакеры пишут, что они попросту купили доступ к зараженному серверу у автора Gozi, и сервер стал отправной точкой входа.

    Ну т.е. они даже эксплоит не покупали. Даже если б купили - ну приватный эксплоит, обычное дело.
    Безопасность НАСА действительно оставляла желать лучшего: запустив обычный брутфорс, хакеры нашли первое сочетание логина и пароля root:root через 0,32 секунды.

    Закрепились на одной машине, стали сканить с неё все доступные во внутренней сети - простое и логичное действие. root:root это конечно полный фэйл, и можно сказать удача для AnonSec, но в принципе не так уж удивительно и невероятно.
    Хакеры смогли получить полный доступ к сетевым хранилищам данных (NAS) на которых хранились копии всех планов полетов беспилотников

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

    Получили доступ к NAS (снова root:root, или зашли с доверенной машины, или насобирали паролей разных юзеров и какой-то подошел к NAS), смогли заливать свои файлы. Вот и залили.

    Я не говорю, что со всем этим справился бы школьник, но где вы тут видите что-либо про взлом прошивки? И да, про "закрытые данные":
    взломать внутреннюю сеть НАСА и провести в ней несколько месяцев, а в качестве доказательства они опубликовали архив объёмом 276 ГБ

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

    И под каждый беспилотник никто новую ОС писать не будет. И для серверов НАСА тоже никто новую ОС писать не будет. В беспилотнике будет какой нибудь embedded-дистрибутив, на серверах ну допустим какой-нибудь олдскульный UNIX (AIX/HP-UX/etc), а на новых будет Линух.

    даже софт для управления этим беспилотником

    Ну софт не найдешь, а вот gpx формат известен весьма широко.

    В общем, читайте внимательно, вообще не пойму как сказанное вами относится к содержимому статьи.
    Ответ написан
    Комментировать
  • В чем моя причина провала тестового задания Яндекса?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Ну давайте я покритикую:

    возьмем файлик

    1) вы не разобрались как объявлять методы у прототипов с новой нотацией `class`:

    class Travelsort {
        constructor() {}
        sortTickets(tickets) {}
    }


    2) вы не умеете пользоваться исключениями.
    if (!Array.isArray(cards)) {
        throw new ValueError('Wrong input');
    }


    3) использование let там где должен использоваться const

    4) в принципе использование переменных там где их быть не должно

    5) вы зачем-то реализовали свою функцию сортировки, я не увидел в требованиях отсутствия возможности использовать старый добрый Array.prototype.sort

    6) Общие замечания по кодинг стайлу. snake_case там где должен быть camelCase, пишите с большой буквы то что должно быть с маленькой и т.д.

    7) нарушения принципа единой ответственности. У вас объеткт умеет и сортировать и писать куда-то. Это категорически плохо.

    8) Если исправить 7-ой пункт то наш класс превращается просто в функцию.

    Далее... берем следующий файлик

    1) если вы пишите комментарии к таким маленьким кускам кода - стало быть у вас хромает именование вещей. Все должн быть понятно просто из названий методов/функций/переменных. При работе в команде над серьезными проектами это немаловажно, ибо код чаще читают чем пишут и экономить нужно именно это время.

    2) вы зачем-то тут в прототип объекта строки впихиваете функции для парсинга CSS. Таким образом мы нарушаем принцип единой ответственности. Да и в целом расширять без надобности прототипы объектов как-то не ок.

    Чуть дальше проскролил - вы пытаетесь расширить прототип строк для того что бы добиться API jquery? ух, батенька.

    3) очень много дублирования.

    4) очень плохо с protected variations.

    Справедливости ради, ваш код входит в категорию ">50% JS кода", так что не расстраивайтесь. Просто для работы в яндексе нужен чуть более высокий уровень и понимание вещей.
    Ответ написан
    17 комментариев
  • Что делать, если запутался в css?

    Elwen
    @Elwen
    1) Адаптивная - это, грубо говоря, фиксированная верстка, которая использует медиа запросы для того, что бы подстроится под устройство просмотра. Отзывчивая - это резиновая верстка с использованием тех же медиа запросов для того же. В свое время именно такое объяснение показалось мне самым простым и понятным. Но большинство заказчиков все равно воспринимает это как одно и тоже, так что объяснять будет дольше.
    Есть замечательный сайт liquidapsive.com, который очень наглядно показывает разницу между разными типами верстки (адаптивная, отзывчивая, фиксированная и резиновая) на примере одного макета. К нему же есть отличная статья на frontender.info, где довольно доходчиво рассказано о разных подходах, их плюсах и минусах.
    2) Как бы то ни было, это все же зависит от проекта. Резиновая верстка отлично подходит для большинства сайтов, но есть проекты, где целесообразней все же сделать отдельно мобильную версию. Например, соц. сети.
    3) Нет.
    4) К сожалению, есть много вопросов относительно возможностей и развития css.
    5) Единственного верного способа решить поставленную задачу в программировании нет. В большинстве случаев есть несколько способов. Бывает что одно решение выигрывает по тем или иным параметрам у другого. И каждый программист иногда чувствует, что его творение больше походит на монстра, чем на чистый код. Это вовсе не означает, что это так (хотя случается и такое, чего таить). В любом случае, взглянув на свой код, который сейчас вам кажется хорошим, через несколько лет, скорее всего, вы схватитесь за голову) Стремитесь совершенствоваться, но не зацикливайтесь на этом.
    Ответ написан
    2 комментария
  • Почему нет сильной Ecommerce платформы под node.js?

    @xfg
    Потому что на node.js как не пиши, но любое более менее сложное приложение превращается в процедурную лапшу. Абстракций и полиморфизма типов нет, приходится зависеть от конкретных реализаций. В метеоре на котором вы написали свое приложение нет di контейнера, всё валится в глобальную область видимости, используется монго, не поддерживаются транзакции между документами/коллекциями, сильная связанность, тяжело покрыть тестами.

    Впечатление от этого всего, что вернулся в начало 2000-ых. Нужно ждать, пока спецификацию ecmascript допилят до вменяемого состояния. Но я думаю, что к тому времени в том же php уже будет асинхронность из коробки, тем более у разработчиков это в планах.
    Ответ написан
    9 комментариев
  • Как урезать свой перфекционизм?

    isqua
    @isqua
    Научу HTML, CSS, JS, BEM и Git
    Чтобы перестать делать лучше то, что ещё не сделано до конца, нужно понять одну простую истину: Запущенный проект лучше, чем не запущенный.

    Давайте потренируемся:
    • Что лучше: запущенный проект с несжатыми стилями или незапущенный со сжатыми?
    • Что лучше: не запущенный проект с десятью страницами или запущенный с тремя?
    • Что лучше: запущенный проект c jQuery или не запущенный без jQuery?


    Надеюсь, вы смогли выбрать! Как узнать, что пора запустить проект? (Под запуском я имею в виду «показать людям». Например, если вы решили написать библиотеку, давайте считать «проект запущенным», если вы выложили её на гитхаб) Нужно прикинуть, сколько времени вам надо на разработку и умножить на два. Если получилось больше двух недель, то стоит разбить проект на части и прикинуть так про каждую часть. Соответственно, ставите дедлайны.

    Промежуточные дедлайны помогают успеть к последнему. Старайтесь сначала реализовать основную функциональность, а потом дополнительную. Если не успеете к дедлайну доделать дополнительное — сначала запустите основное, а потом видно будет, надо ли вообще доделывать дополнительное.

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

    Удачи!
    Ответ написан
    4 комментария
  • Реально ли создать стартап без бюджета в наше время?

    un1t
    @un1t
    Фейсбук без бюджета? О_о А инвестиции не считаются чтоли?
    Истории про стартапы звучат примерно так. Жил был чувак, пилил пол года дома один или с кем-то какую-то хрень. Потом бац и стартап взлетел. Обычно истории умалчивают, что у этого чувака папа директор курпного междунородного банка, а мама работает в правительстве. И потом еще оказывается, что он делал не сам, а вообще нанял каких-то чуваков за 10 тыщ баксов, ну типа на завтраках школьных сэкономил.
    Ну и даже если папа и мама у него самые обычные, то чтобы пол года или год сидеть дома и пилить какую-то хрень нужен приличный бюджет, просто хотябы на проживание, аренду, еду и прочее. Ну и все равно что-то надо еще оставить на рекламу и т.п.
    Историй масштаба фейсбука без вложений не бывает.
    Более мелкое что-то может быть, но тоже не без вложений, нужны меньшие вложения. Накопить немного денег и сделать что-то небольшое вполне реально. Ну там газель купить и в аренду сдавать например) Или киоск с шурмой поставить.
    Ответ написан
    2 комментария
  • Можно ли вылечить?

    Jump
    @Jump Куратор тега Твердотельные накопители
    Системный администратор со стажем.
    Нет.
    Ответ написан
    Комментировать
  • Как очистить git?

    POS_troi
    @POS_troi
    СадоМазо Админ, флудер, троль.
    Создайте новый репозиторий и покладите в него свои файлики, старый оставьте на память :)
    Ответ написан
    Комментировать
  • Как долго может длится прикрепление домена?

    ну давайте думать логически:

    пока вы не прикрепили вашдомен.tk к сайту на Юкоз, вас будет кидать на заглушку вашдомен.tk
    для того чтобы вас перенаправляло куда надо проделайте такую операцию с вашими ns серверами prntscr.com/a8ifsz и соответственно вкладка как у меня будет пустая prntscr.com/a8ig03

    другой вариант это перенаправление с вашдомен.tk на вашсубдомен.ucoz.com

    вообще операция по присваиванию домена не больше суток времени занимала раньше, сейчас это делают на много быстрее
    Ответ написан
    4 комментария
  • Считается ли плохой практикой выражения в значениях массива?

    @SergeyZelensky-Rostov
    $arr['key'] = Class::do($data);
    Ответ написан
    Комментировать
  • Как восстановить/взломать утерянный ssh public key?

    @werw
    Смысл всей этой хрени с ключами, чтобы это было невозможно сделать в принципе.
    Не ссы против ветра.
    Ответ написан
    Комментировать