<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Rss on Adam Swiderski</title><link>https://swiderski.tech/categories/rss/</link><description>Recent content in Rss on Adam Swiderski</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><managingEditor>aswiderski@pm.me (Adam Świderski)</managingEditor><webMaster>aswiderski@pm.me (Adam Świderski)</webMaster><lastBuildDate>Thu, 06 Aug 2020 00:00:00 +0000</lastBuildDate><atom:link href="https://swiderski.tech/categories/rss/index.xml" rel="self" type="application/rss+xml"/><item><title>Code Review Retro</title><link>https://swiderski.tech/code-review-retro/</link><pubDate>Thu, 06 Aug 2020 00:00:00 +0000</pubDate><author>aswiderski@pm.me (Adam Świderski)</author><guid>https://swiderski.tech/code-review-retro/</guid><description>Importance of Code Review I sure do hope that I don&amp;rsquo;t need to convince anyone how important is the process of code review. If you need some guidelines on how to do it well I can recommend this Yelp blog post Here I&amp;rsquo;d just like to perform a retrospective of my own code review experiences.
A bit of history When I started my developer career in a rather small company - we were not doing code reviews.</description></item><item><title>Ultimate Github Page Deployment</title><link>https://swiderski.tech/github-page-deployment/</link><pubDate>Tue, 04 Aug 2020 00:00:00 +0000</pubDate><author>aswiderski@pm.me (Adam Świderski)</author><guid>https://swiderski.tech/github-page-deployment/</guid><description>Mr Hyde Text you are reading is available on Jekyll blog hosted on GitHub, with the use of free Github Pages. Long story short: Jekyll is a template engine changing markdown documents on static HTML webpages, that you can then host anywyere, because you don&amp;rsquo;t need databases or server that has PHP or Python.
Usual process Normally process of adding new post looks like this:
I write markdown document with setting parameters like title, date and tags when I&amp;rsquo;m happy with what I wrote (never), I commit changes and push it to repository on GitHub.</description></item><item><title>IntelliJ settings repo</title><link>https://swiderski.tech/intellij-settings-repo/</link><pubDate>Sun, 19 Jul 2020 00:00:00 +0000</pubDate><author>aswiderski@pm.me (Adam Świderski)</author><guid>https://swiderski.tech/intellij-settings-repo/</guid><description>My setup looks like this: I have Windows PC with Linux installed on a separate drive, also I have 2 MacBooks for work, and rarely used Linux ThinkPad. Keeping my IntelliJ settings in sync at all of those machines wasn&amp;rsquo;t really possible. If I find some setting that improves my workflow at my office machine, and after some time I want to work on a pet project on my own PC - I get this itch of not having this setting I had on MacBook&amp;hellip; so I can export my settings and then import it.</description></item><item><title>Shell script basics</title><link>https://swiderski.tech/shellscriptbasics/</link><pubDate>Sun, 03 May 2020 00:00:00 +0000</pubDate><author>aswiderski@pm.me (Adam Świderski)</author><guid>https://swiderski.tech/shellscriptbasics/</guid><description>Why Recently I had to do some tasks that required me to fallowing a strict checklist. It wasn&amp;rsquo;t anything complex, no creativity required - just do as list tells you to do. I was also one of the creators of the checklist.
I had to do it a few times, almost regularly, sometimes in short notice but nothing extreme.
So obviously I made errors because I knew the checklist so well I wasn&amp;rsquo;t paying attention.</description></item><item><title>Overlibrarization</title><link>https://swiderski.tech/overlibrarization/</link><pubDate>Sun, 20 Jan 2019 18:57:02 +0000</pubDate><author>aswiderski@pm.me (Adam Świderski)</author><guid>https://swiderski.tech/overlibrarization/</guid><description>It seems great Write code once use it many times. Creating smaller pieces of code forces developers to write encapsulated software that follows single responsibility principle and is easy to test. Such code piece (AKA module) can be then published as a versioned artifact - a private library, that can be reused in more than one project. We are getting quality and reusability, how cool is that! Well that&amp;rsquo;s the theory.</description></item><item><title>Android build hacks #3 - documentation with Dokka</title><link>https://swiderski.tech/android-build-hacks-3-documentation/</link><pubDate>Mon, 05 Nov 2018 20:05:58 +0000</pubDate><author>aswiderski@pm.me (Adam Świderski)</author><guid>https://swiderski.tech/android-build-hacks-3-documentation/</guid><description>This is third part in series of articles about Android build configuration, all parts will be linked right below.
#1 Build basics
#2 Build time optimization
#3 Documentation with Dokka
Homework Wait what? You&amp;rsquo;ve wrote beautiful self-documenting code and someone tells you to create DOCUMENTATION for it? It&amp;rsquo;s already there! Well named methods and variables, design patterns used. If anyone wants to know how it works, he just needs to read through it - well named method by well named method&amp;hellip;</description></item><item><title>Android Build Hacks #2 - build time optimization</title><link>https://swiderski.tech/android-build-hacks-2/</link><pubDate>Sun, 16 Sep 2018 10:36:34 +0000</pubDate><author>aswiderski@pm.me (Adam Świderski)</author><guid>https://swiderski.tech/android-build-hacks-2/</guid><description>This is second part in series of articles about Android build configuration, all parts will be linked right below.
#1 Build basics
#2 Build time optimization
Motivation Main reason I&amp;rsquo;ve been interested in build config tricks was to speed up development builds. As developer I&amp;rsquo;m building apps many times each day, often just to change one small thing and check if it works. Each second took of build time means a lot if you build often.</description></item><item><title>Android Build Hacks #1 - build basics</title><link>https://swiderski.tech/android-build-hacks-1/</link><pubDate>Mon, 23 Jul 2018 22:24:27 +0000</pubDate><author>aswiderski@pm.me (Adam Świderski)</author><guid>https://swiderski.tech/android-build-hacks-1/</guid><description>This is first part in series of articles about Android build configuration, all parts will be linked right below.
#1 Build basics
#2 Build time optimization
Build configuration! This is not the most exciting part of software engineering. Each technology, language, framework has it&amp;rsquo;s own rules so there are no universal patterns, Uncle Bob will not help us here. But just like this worker on left, tightening the screw of Empire State Building skeleton, developers should polish their builds - build config itself is not the application (like skeleton is not the building), but application is useless if you cannot build release version.</description></item><item><title>Hacking Android app with Frida</title><link>https://swiderski.tech/android-frida-hacking/</link><pubDate>Sat, 31 Mar 2018 17:43:37 +0000</pubDate><author>aswiderski@pm.me (Adam Świderski)</author><guid>https://swiderski.tech/android-frida-hacking/</guid><description>Side image is of course Frida Kahlo auto portrait, besides her name she has no connection with topic
Motivation Lately I attended to Sekurak hacking party - it&amp;rsquo;s event organized by Sekurak where they show how easy is to hack stuff like IP cameras, routers, phones. I guess Sekurak is known mainly in Poland, but they are real professionals in area of security. During this event Michał Bentkowski was showing how easy it is to spy on Android app communication and also change app behavior using tool named Frida.</description></item><item><title>Nyan your terminal</title><link>https://swiderski.tech/nyan-your-terminal/</link><pubDate>Sun, 04 Mar 2018 08:23:03 +0000</pubDate><author>aswiderski@pm.me (Adam Świderski)</author><guid>https://swiderski.tech/nyan-your-terminal/</guid><description>Disclaimer #1: I&amp;rsquo;m an Android developer, not sysadmin. I use terminal to help me with my workflow, not as my main tool, so please keep this in mind :)
Disclaimer #2: This is based on Linux (Ubuntu), but most stuff should work on OSX also.
Terminal? If you are a developer (and not a Windows peasant), you might had to use terminal for day to day stuff like installing node.js or python packages, or running scripts.</description></item></channel></rss>