The Hashtag Generator
Маркетологи тратят слишком много времени на введение хэштегов. Давайте поможем им с помощью нашего собственного генератора хэштегов!
Вот что нужно сделать:
✓ Все слова должны начинаться с хэштега (#).
✓ Все слова должны быть написаны с заглавной буквы.
✓ Если конечный результат длиннее 140 символов, он должен вернуть false.
✓ Если входные данные или результат - пустая строка, то он должен возвращать false.
Пример:
👉 @seniorFront
Маркетологи тратят слишком много времени на введение хэштегов. Давайте поможем им с помощью нашего собственного генератора хэштегов!
Вот что нужно сделать:
✓ Все слова должны начинаться с хэштега (#).
✓ Все слова должны быть написаны с заглавной буквы.
✓ Если конечный результат длиннее 140 символов, он должен вернуть false.
✓ Если входные данные или результат - пустая строка, то он должен возвращать false.
Пример:
" Hello there thanks for trying my Kata" => "#HelloThereThanksForTryingMyKata"
" Hello World " => "#HelloWorld"
"" => false
👉 @seniorFront
Топ-10 антипаттернов в разработке ПО, которых стоит избегать
Если вам достался проект, в котором копаться — всё равно что распутывать спагетти в боксерских перчатках, вы, скорее всего, столкнулись с антипаттернами. К этим практикам сначала прибегают как к быстрым решениям, но затем они превращаются в повторяющиеся ночные кошмары. Представьте себе магическую кнопку деплоя, которая ломает всё в 2 часа ночи — а дежурите вы.
Антипаттерны проникают активнее всего, когда команды разработки ставят скорость выше структуры. То, что начинается как невинная короткая дорога, может перерасти в полноценного алгоритмического монстра, подрывая производительность и поддерживаемость. Джоэль Спольски говорит, что «читать код сложнее, чем его писать». А читать такой код попросту больно.
Хорошая новость: вы не застряли в этом. Независимо от того, управляете ли вы кодом внутри компании или работаете с партнёрами по разработке ПО, главное — выявить эти проблемы вовремя. Давайте рассмотрим самые распространённые антипаттерны в программировании, от Спагетти-кода до «Лодочных якорей», с примерами реального кода. Вы научитесь замечать «запашки» на ранней стадии и проводить рефакторинг до того, как ваш продукт станет «Большим комком грязи» (Big Ball of Mud).
👉 @seniorFront
Если вам достался проект, в котором копаться — всё равно что распутывать спагетти в боксерских перчатках, вы, скорее всего, столкнулись с антипаттернами. К этим практикам сначала прибегают как к быстрым решениям, но затем они превращаются в повторяющиеся ночные кошмары. Представьте себе магическую кнопку деплоя, которая ломает всё в 2 часа ночи — а дежурите вы.
Антипаттерны проникают активнее всего, когда команды разработки ставят скорость выше структуры. То, что начинается как невинная короткая дорога, может перерасти в полноценного алгоритмического монстра, подрывая производительность и поддерживаемость. Джоэль Спольски говорит, что «читать код сложнее, чем его писать». А читать такой код попросту больно.
Хорошая новость: вы не застряли в этом. Независимо от того, управляете ли вы кодом внутри компании или работаете с партнёрами по разработке ПО, главное — выявить эти проблемы вовремя. Давайте рассмотрим самые распространённые антипаттерны в программировании, от Спагетти-кода до «Лодочных якорей», с примерами реального кода. Вы научитесь замечать «запашки» на ранней стадии и проводить рефакторинг до того, как ваш продукт станет «Большим комком грязи» (Big Ball of Mud).
👉 @seniorFront
Что такое двустороннее связывание ?
Двустороннее связывание данных (Two-way data binding) — это паттерн проектирования, используемый в разработке пользовательских интерфейсов, при котором пользовательский интерфейс автоматически обновляется при изменении данных, и наоборот, данные автоматически изменяются при модификации пользовательским интерфейсом. Это означает, что модель и представление (view) синхронизированы в реальном времени: изменение в модели немедленно отражается в представлении, и любое изменение в представлении немедленно обновляет модель.
Как это работает
У вас есть текстовое поле в форме (представление) и переменная (модель), которая хранит значение этого текстового поля. С двусторонним связыванием, если пользователь изменяет значение в текстовом поле, переменная в модели будет автоматически обновлена соответствующим образом. Аналогично, если переменная изменяется программно (например, в результате какой-то логики приложения), изменение отразится в текстовом поле.
Оно широко используется в фреймворках и платформах для разработки одностраничных приложений (SPA), таких как Angular. В Angular, например, это достигается с помощью директивы
В этом примере,
Преимущества:
- Упрощение разработки, поскольку не нужно вручную обновлять представление или модель при изменении другой части.
- Улучшение пользовательского опыта, обеспечивая немедленное отображение изменений без дополнительных действий пользователя или дополнительного кода.
Недостатки:
- Сложность отладки, поскольку автоматическое обновление значений в обе стороны может привести к неожиданным эффектам и затруднить трассировку потока данных.
- Производительность, особенно в больших и сложных приложениях, где непрерывная синхронизация данных между моделью и представлением может повлиять на быстродействие.
👉 @seniorFront
Двустороннее связывание данных (Two-way data binding) — это паттерн проектирования, используемый в разработке пользовательских интерфейсов, при котором пользовательский интерфейс автоматически обновляется при изменении данных, и наоборот, данные автоматически изменяются при модификации пользовательским интерфейсом. Это означает, что модель и представление (view) синхронизированы в реальном времени: изменение в модели немедленно отражается в представлении, и любое изменение в представлении немедленно обновляет модель.
Как это работает
У вас есть текстовое поле в форме (представление) и переменная (модель), которая хранит значение этого текстового поля. С двусторонним связыванием, если пользователь изменяет значение в текстовом поле, переменная в модели будет автоматически обновлена соответствующим образом. Аналогично, если переменная изменяется программно (например, в результате какой-то логики приложения), изменение отразится в текстовом поле.
Оно широко используется в фреймворках и платформах для разработки одностраничных приложений (SPA), таких как Angular. В Angular, например, это достигается с помощью директивы
[(ngModel)], которая связывает значение HTML элемента формы (например, <input>) с свойством компонента.<input [(ngModel)]="user.name">
В этом примере,
user.name — это свойство компонента, которое связано с текстовым полем. Любое изменение в поле ввода немедленно обновит user.name, и любое изменение user.name будет немедленно отражено в поле ввода.Преимущества:
- Упрощение разработки, поскольку не нужно вручную обновлять представление или модель при изменении другой части.
- Улучшение пользовательского опыта, обеспечивая немедленное отображение изменений без дополнительных действий пользователя или дополнительного кода.
Недостатки:
- Сложность отладки, поскольку автоматическое обновление значений в обе стороны может привести к неожиданным эффектам и затруднить трассировку потока данных.
- Производительность, особенно в больших и сложных приложениях, где непрерывная синхронизация данных между моделью и представлением может повлиять на быстродействие.
👉 @seniorFront
👍3❤1
This media is not supported in your browser
VIEW IN TELEGRAM
Cool Layout with Complex Chainable Animation
Создано и анимировано на HTML и SCSS. При нажатии на элемент запускается CSS анимация через событие click, обработанное в JS.
👉 @seniorFront
Создано и анимировано на HTML и SCSS. При нажатии на элемент запускается CSS анимация через событие click, обработанное в JS.
👉 @seniorFront
🔥6❤3👍3👎1
SOSAL: Современный социальный подход к программированию
В мире программирования существуют различные идеологии написания кода, которые отвечают за коммуникации (Unix-way), гибкость (Agile), чистоту и читаемость кода (DRY, KISS).
Все они помогают улучшить ваш код, но их уязвимость в единоличности программиста и его продукта, именно поэтому я выработал новую, социальную идеологию написания кода.
Подход к программированию SOSAL основывается на предположении взаимодействия в процессе разработки множества самых различных людей. SOSAL позволяет адаптировать его для максимального удобства и продуктивности всей команды.
SOSAL состоит из пяти принципов, каждый из них будет подробно описан в отдельных абзацах:
1. Socially-Conscious Code гласит о самом главном концепте работы в команде: кооперации. Для создания дружелюбной кодовой базы, каждому последователю идеологии SOSAL необходимо подробно изучить язык, но необычным образом. Самые главные части языка при работе в команде это стиль кода, чистота кода и идиоматические подходы: изучите стиль кода, распространённые методы решения проблем в языке. Это позволит остальным программистам команды быстрее влиться в решение рабочих задач.
2. Open by Default призывает к открытости кода, при отсутствии причин для обратного. Также этот принцип рекомендует комментировать код так, как будто его читают те, кто только учится программировать. Понять когда нужно комментировать или нет в этом случае очень просто (при условии что вы достаточно хороший программист): если решение проблемы не возникает машинально, или возникает через достаточно длительный срок, то рекомендуется оставить комментарий.
3. Simple Scalability рекомендует писать код, который легко масштабируется. Но стоит сказать, что реализация преждевременных оптимизаций – зло. Простота не есть примитивность, также как сложность не есть крутость.
4. Agile Adaptivity говорит о том, что код должен быть готов к изменениям, даже если они кажутся маловероятными. Обычно, при разработке сложных консольных утилит, я беру готовую библиотеку для обработки флагов и настроек, так как конфигурация на стадии разработки может очень сильно меняться. Стоит соблюдать границу между YAGNI (You Aren't Gonna Need It) и возможностью «эволюции» кодовой базы.
5. Learning-Driven Logic (Логика, основанная на обучении)Learning-Driven Logic призывает писать свой код так, чтобы в процессе написания он учил тебя и других. Рефакторинг – не наказание, а повод применить свои навыки.
👉 @seniorFront
В мире программирования существуют различные идеологии написания кода, которые отвечают за коммуникации (Unix-way), гибкость (Agile), чистоту и читаемость кода (DRY, KISS).
Все они помогают улучшить ваш код, но их уязвимость в единоличности программиста и его продукта, именно поэтому я выработал новую, социальную идеологию написания кода.
Подход к программированию SOSAL основывается на предположении взаимодействия в процессе разработки множества самых различных людей. SOSAL позволяет адаптировать его для максимального удобства и продуктивности всей команды.
SOSAL состоит из пяти принципов, каждый из них будет подробно описан в отдельных абзацах:
1. Socially-Conscious Code гласит о самом главном концепте работы в команде: кооперации. Для создания дружелюбной кодовой базы, каждому последователю идеологии SOSAL необходимо подробно изучить язык, но необычным образом. Самые главные части языка при работе в команде это стиль кода, чистота кода и идиоматические подходы: изучите стиль кода, распространённые методы решения проблем в языке. Это позволит остальным программистам команды быстрее влиться в решение рабочих задач.
2. Open by Default призывает к открытости кода, при отсутствии причин для обратного. Также этот принцип рекомендует комментировать код так, как будто его читают те, кто только учится программировать. Понять когда нужно комментировать или нет в этом случае очень просто (при условии что вы достаточно хороший программист): если решение проблемы не возникает машинально, или возникает через достаточно длительный срок, то рекомендуется оставить комментарий.
3. Simple Scalability рекомендует писать код, который легко масштабируется. Но стоит сказать, что реализация преждевременных оптимизаций – зло. Простота не есть примитивность, также как сложность не есть крутость.
4. Agile Adaptivity говорит о том, что код должен быть готов к изменениям, даже если они кажутся маловероятными. Обычно, при разработке сложных консольных утилит, я беру готовую библиотеку для обработки флагов и настроек, так как конфигурация на стадии разработки может очень сильно меняться. Стоит соблюдать границу между YAGNI (You Aren't Gonna Need It) и возможностью «эволюции» кодовой базы.
5. Learning-Driven Logic (Логика, основанная на обучении)Learning-Driven Logic призывает писать свой код так, чтобы в процессе написания он учил тебя и других. Рефакторинг – не наказание, а повод применить свои навыки.
👉 @seniorFront
🤔20🔥9👎4
Информационная безопасность для цифровых кочевников
Сейчас я занимаюсь проектом по внедрению дополнительных механизмов проверки прав пользователей при доступе к корпоративным ресурсам. Этот опыт помог мне иначе взглянуть на угрозы, с которыми сталкиваются сотрудники, работающие удалённо и при этом часто меняющие место работы.
В этой статье я хочу поделиться своими наблюдениями. Возможно, они помогут вам лучше защитить себя в дороге и заодно по-новому взглянуть на риски мобильной работы.
👉 @seniorFront
Сейчас я занимаюсь проектом по внедрению дополнительных механизмов проверки прав пользователей при доступе к корпоративным ресурсам. Этот опыт помог мне иначе взглянуть на угрозы, с которыми сталкиваются сотрудники, работающие удалённо и при этом часто меняющие место работы.
В этой статье я хочу поделиться своими наблюдениями. Возможно, они помогут вам лучше защитить себя в дороге и заодно по-новому взглянуть на риски мобильной работы.
👉 @seniorFront
❤1👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Masked Circle Slider
Логика работы карусели реализована при помощи библиотеки slick-carousel. Элементы карусели - это SVG картинки, анимированные в JS.
👉 @seniorFront
Логика работы карусели реализована при помощи библиотеки slick-carousel. Элементы карусели - это SVG картинки, анимированные в JS.
👉 @seniorFront
👍4🔥2
Media is too big
VIEW IN TELEGRAM
Animated Click Effect
В этом видео создается анимированные эффект при клике на CSS и JS.
👉 @seniorFront
В этом видео создается анимированные эффект при клике на CSS и JS.
👉 @seniorFront
👍2
This media is not supported in your browser
VIEW IN TELEGRAM
Animating svg polygon points
В HTML создана svg картинка. В ней есть элементы <polygon/>, которые анимируются библиотекой TweenMax.
👉 @seniorFront
В HTML создана svg картинка. В ней есть элементы <polygon/>, которые анимируются библиотекой TweenMax.
👉 @seniorFront
🔥8
Какой CSS селектор выберет элементы, у которых атрибут href начинается с "https"?
Anonymous Quiz
32%
a[href*="https"]
16%
a[href$="https"]
44%
a[href^="https"]
7%
a[href~="https"]
👍2👎2
This media is not supported in your browser
VIEW IN TELEGRAM
SVG Mask Slider
Внутри слайдера находятся SVG картинки, анимированные библиотекой TweenMax.
👉 @seniorFront
Внутри слайдера находятся SVG картинки, анимированные библиотекой TweenMax.
👉 @seniorFront
👍5
Valid Braces
Создайте функцию, которая принимает строку скобок и определяет, является ли порядок скобок правильным. Она должна возвращать
Все входные строки будут непустыми и состоять только из круглых скобок, скобок и фигурных скобок:
Что считается валидным?
Строка скобок считается валидной, если все скобки сопоставлены с правильной скобкой.
Примеры:
👉 @seniorFront
Создайте функцию, которая принимает строку скобок и определяет, является ли порядок скобок правильным. Она должна возвращать
true, если строка допустима, и false, если недопустима.Все входные строки будут непустыми и состоять только из круглых скобок, скобок и фигурных скобок:
()[]{}. Что считается валидным?
Строка скобок считается валидной, если все скобки сопоставлены с правильной скобкой.
Примеры:
"(){}[]" => True
"([{}])" => True
"(}" => False
"[(])" => False
"[({})](]" => False👉 @seniorFront
Краткая история JavaScript
В этом году JavaScript исполняется 30 лет.
За три десятилетия он прошел путь от забавного и непритязательного скриптового языка, созданного за 10 дней, до самого популярного языка программирования в мире. В статье — ключевые моменты истории JavaScript, которые помогут понять, как он менялся и куда идет.
👉 @seniorFront
В этом году JavaScript исполняется 30 лет.
За три десятилетия он прошел путь от забавного и непритязательного скриптового языка, созданного за 10 дней, до самого популярного языка программирования в мире. В статье — ключевые моменты истории JavaScript, которые помогут понять, как он менялся и куда идет.
👉 @seniorFront
Что такое this?
this является ключевым словом, которое используется в функциях и методах и указывает на объект, в контексте которого они были вызваны.Его значение зависит от того, как именно вызывается функция, и может изменяться в различных контекстах выполнения.
Контексты использования:
1. Глобальный контекст:
В глобальном контексте (вне каких-либо функций) он ссылается на глобальный объект. В браузере глобальным объектом является window, в Node.js — global.
2. Функции (не строгий режим):
В функциях, вызванных обычным способом (не как методы объекта), он ссылается на глобальный объект. В строгом режиме (
3. Методы объекта:
Когда функция вызывается как метод объекта, он ссылается на объект, частью которого является метод.
4. Конструкторы:
В функции-конструкторе, вызванной с
5. Стрелочные функции:
Стрелочные функции не имеют собственного контекста, вместо этого они захватывают его из внешнего лексического окружения.
6. Явное привязывание:
С помощью методов
👉 @seniorFront
this является ключевым словом, которое используется в функциях и методах и указывает на объект, в контексте которого они были вызваны.Его значение зависит от того, как именно вызывается функция, и может изменяться в различных контекстах выполнения.
Контексты использования:
1. Глобальный контекст:
В глобальном контексте (вне каких-либо функций) он ссылается на глобальный объект. В браузере глобальным объектом является window, в Node.js — global.
console.log(this === window); // в браузере вернет true
2. Функции (не строгий режим):
В функциях, вызванных обычным способом (не как методы объекта), он ссылается на глобальный объект. В строгом режиме (
"use strict") this будет undefined, если функция вызвана не как метод объекта. function show() {
console.log(this === window); // true в браузере в нестрогом режиме
console.log(this); // undefined в строгом режиме
}
show();3. Методы объекта:
Когда функция вызывается как метод объекта, он ссылается на объект, частью которого является метод.
const obj = {
myMethod() {
console.log(this);
}
};
obj.myMethod(); // this ссылается на obj4. Конструкторы:
В функции-конструкторе, вызванной с
new, он ссылается на вновь созданный объект.function Person(name) {
this.name = name;
}
const person = new Person("Alice");
console.log(person.name); // Alice5. Стрелочные функции:
Стрелочные функции не имеют собственного контекста, вместо этого они захватывают его из внешнего лексического окружения.
const obj = {
method: function() {
const arrowFunc = () => console.log(this);
arrowFunc(); // this ссылается на obj
}
};
obj.method();6. Явное привязывание:
С помощью методов
call, apply и bind можно явно указать контекст для функции.function show() {
console.log(this);
}
const obj = {name: "Explicit context"};
show.call(obj); // this в show() ссылается на obj👉 @seniorFront
👍14❤4
This media is not supported in your browser
VIEW IN TELEGRAM
Envelope Open Animation with Hearts
Свёрстано и анимировано на HTML и SCSS. Логика открытия конверта и запуска анимаций реализована в JS.
👉 @seniorFront
Свёрстано и анимировано на HTML и SCSS. Логика открытия конверта и запуска анимаций реализована в JS.
👉 @seniorFront
👍2
Путь из разраба в лида: что я понял об ответственности
Переход в лиды из разработчика — дело не простое. Нужно научиться слушать людей, видеть их сильные стороны, разбираться в мотивации и много чего еще. Сейчас я Dev Lead в Exante. Мы разрабатываем внутренние сервисы для узкого круга заказчиков. Мой путь в лиды начался с неформального лидерства и первых попыток менторства.
Усвоенные уроки
1. Фидбек — это нормально. Не важно, хороший он или плохой. Давайте его честно, но тактично — неприятные моменты лучше вставлять между позитивными, чтобы смягчить удар. И не забывайте самому просить фидбек на себя как лида — это помогает расти, даже если не всегда приятно.
2. Вы — мост между разрабами и бизнесом. Лид — это не просто координатор задач, а проводник между разработчиками и бизнесом. Ваша задача — замечать проблемы раньше всех, находить компромиссы и поддерживать баланс между интересами команды и компании.
3. Не всех можно замотивировать. Некоторые люди просто не выкладываются на 100%, и ты ничего с этим не сделаешь. В таких случаях важно честно сообщить руководству, что человек не подходит команде.
4. Берите на себя ответственность. Лидерство начинается с готовности принимать решения и нести за них ответственность. Иногда лучше попробовать и ошибиться, чем ждать, пока кто-то другой возьмёт инициативу.
5. Тяните за собой команду. Если кто-то буксует — помогайте. Иногда это значит просто подсказать, иногда — сходить в соседний отдел и спросить, как коллеги решали похожие задачи. Вместе вы сможете двигаться быстрее.
6. Фейлы — часть пути. Ошибки неизбежны. Главное — понять, почему так произошло, сделать выводы и двигаться дальше. Через год любой фейл превращается в байку, которую приятно вспоминать на корпоративе.
7. Делегируйте, но держите руку на пульсе. Не пытайтесь завязать всё на себе. Дайте команде проявить себя, но не отпускай задачи полностью. Контролируйте ключевые точки, чтобы вовремя заметить, если что-то идёт не так.
8. Предлагайте идеи, но будь готов к отказу.
Даже самые крутые идеи могут не сработать из-за специфики проекта. Учитесь слушать команду, находить причины отказа и адаптировать свои предложения.
9. Проводите встречи один-на-один.
Эти беседы важны не только для фидбека по задачам, но и для построения доверия. Иногда такие разговоры помогают увидеть скрытые проблемы и лучше понять команду.
10. Не выносите фейлы на общие собрания. Ошибки лучше разбирать на личных встречах — это снижает стресс и позволяет обсуждать промахи честно и открыто. Общие митинги лучше использовать для обсуждения успехов и планов.
11. Документируйте процессы. Плохая документация кода лучше, чем ее полное отсутствие. Записывайте ключевые моменты, команды и решения — потом скажете себе за это спасибо.
12. Гибкость — ключ к успеху. Люди разные, и то, что работает с одним, может оказаться бесполезным с другим. Лидер должен быть готов менять подходы, адаптироваться и искать индивидуальные решения.
👉 @seniorFront
Переход в лиды из разработчика — дело не простое. Нужно научиться слушать людей, видеть их сильные стороны, разбираться в мотивации и много чего еще. Сейчас я Dev Lead в Exante. Мы разрабатываем внутренние сервисы для узкого круга заказчиков. Мой путь в лиды начался с неформального лидерства и первых попыток менторства.
Усвоенные уроки
1. Фидбек — это нормально. Не важно, хороший он или плохой. Давайте его честно, но тактично — неприятные моменты лучше вставлять между позитивными, чтобы смягчить удар. И не забывайте самому просить фидбек на себя как лида — это помогает расти, даже если не всегда приятно.
2. Вы — мост между разрабами и бизнесом. Лид — это не просто координатор задач, а проводник между разработчиками и бизнесом. Ваша задача — замечать проблемы раньше всех, находить компромиссы и поддерживать баланс между интересами команды и компании.
3. Не всех можно замотивировать. Некоторые люди просто не выкладываются на 100%, и ты ничего с этим не сделаешь. В таких случаях важно честно сообщить руководству, что человек не подходит команде.
4. Берите на себя ответственность. Лидерство начинается с готовности принимать решения и нести за них ответственность. Иногда лучше попробовать и ошибиться, чем ждать, пока кто-то другой возьмёт инициативу.
5. Тяните за собой команду. Если кто-то буксует — помогайте. Иногда это значит просто подсказать, иногда — сходить в соседний отдел и спросить, как коллеги решали похожие задачи. Вместе вы сможете двигаться быстрее.
6. Фейлы — часть пути. Ошибки неизбежны. Главное — понять, почему так произошло, сделать выводы и двигаться дальше. Через год любой фейл превращается в байку, которую приятно вспоминать на корпоративе.
7. Делегируйте, но держите руку на пульсе. Не пытайтесь завязать всё на себе. Дайте команде проявить себя, но не отпускай задачи полностью. Контролируйте ключевые точки, чтобы вовремя заметить, если что-то идёт не так.
8. Предлагайте идеи, но будь готов к отказу.
Даже самые крутые идеи могут не сработать из-за специфики проекта. Учитесь слушать команду, находить причины отказа и адаптировать свои предложения.
9. Проводите встречи один-на-один.
Эти беседы важны не только для фидбека по задачам, но и для построения доверия. Иногда такие разговоры помогают увидеть скрытые проблемы и лучше понять команду.
10. Не выносите фейлы на общие собрания. Ошибки лучше разбирать на личных встречах — это снижает стресс и позволяет обсуждать промахи честно и открыто. Общие митинги лучше использовать для обсуждения успехов и планов.
11. Документируйте процессы. Плохая документация кода лучше, чем ее полное отсутствие. Записывайте ключевые моменты, команды и решения — потом скажете себе за это спасибо.
12. Гибкость — ключ к успеху. Люди разные, и то, что работает с одним, может оказаться бесполезным с другим. Лидер должен быть готов менять подходы, адаптироваться и искать индивидуальные решения.
👉 @seniorFront
👍9🤔1
Как я выполнил 1000+ заказов на фрилансе без единого негатива: что я понял за годы удалённой работы
Фриланс — это не про свободу, а про ответственность, дисциплину, прозрачность и умение выстраивать процессы. В этой статье — конкретные принципы, которые помогли мне выполнить 1000+ заказов на разных платформах, удержать 0 негативных отзывов, войти в топы рейтингов и получать более 70% повторных заказов.
👉 @seniorFront
Фриланс — это не про свободу, а про ответственность, дисциплину, прозрачность и умение выстраивать процессы. В этой статье — конкретные принципы, которые помогли мне выполнить 1000+ заказов на разных платформах, удержать 0 негативных отзывов, войти в топы рейтингов и получать более 70% повторных заказов.
👉 @seniorFront
👍2
This media is not supported in your browser
VIEW IN TELEGRAM
RemindMe App Concept
Приложение - напоминалка о том, что пора выпить, реализованное на Vue.
👉 @seniorFront
Приложение - напоминалка о том, что пора выпить, реализованное на Vue.
👉 @seniorFront
👍4