<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: Telichkin</title><link>https://news.ycombinator.com/user?id=Telichkin</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Wed, 30 Sep 2026 03:18:04 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=Telichkin" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by Telichkin in "Synchronous vs. Asynchronous Code Review"]]></title><description><![CDATA[
<p>I've found that most of the time dev teams use async workflow for code reviews. But it delays releases and leads to a lot of postponed context switches. In my experience, sync code reviews that have higher priority over other tasks is a much more productive workflow. With sync reviews we can deliver faster and improve the quality of the codebase</p>
]]></description><pubDate>Wed, 31 Aug 2022 17:38:57 +0000</pubDate><link>https://news.ycombinator.com/item?id=32665671</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=32665671</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=32665671</guid></item><item><title><![CDATA[Synchronous vs. Asynchronous Code Review]]></title><description><![CDATA[
<p>Article URL: <a href="https://convincedcoder.com/2019/02/02/Code-review-collaboration-workflows/">https://convincedcoder.com/2019/02/02/Code-review-collaboration-workflows/</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=32665559">https://news.ycombinator.com/item?id=32665559</a></p>
<p>Points: 1</p>
<p># Comments: 1</p>
]]></description><pubDate>Wed, 31 Aug 2022 17:29:46 +0000</pubDate><link>https://convincedcoder.com/2019/02/02/Code-review-collaboration-workflows/</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=32665559</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=32665559</guid></item><item><title><![CDATA[New comment by Telichkin in "The art project is dedicated to all space pioneers"]]></title><description><![CDATA[
<p>The "About" section of this art project:<p>We have tried to show the most important events in the history of space exploration: first spacecrafts, flights to other planets and landings on celestial bodies.<p>We believe that achievements in space belong to all mankind. We believe that space exploration is a significant step in the evolution of our civilization.</p>
]]></description><pubDate>Mon, 17 Feb 2020 15:45:43 +0000</pubDate><link>https://news.ycombinator.com/item?id=22348458</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=22348458</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=22348458</guid></item><item><title><![CDATA[The art project is dedicated to all space pioneers]]></title><description><![CDATA[
<p>Article URL: <a href="http://inspacewetrust.org/en/">http://inspacewetrust.org/en/</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=22348417">https://news.ycombinator.com/item?id=22348417</a></p>
<p>Points: 1</p>
<p># Comments: 1</p>
]]></description><pubDate>Mon, 17 Feb 2020 15:41:12 +0000</pubDate><link>http://inspacewetrust.org/en/</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=22348417</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=22348417</guid></item><item><title><![CDATA[New comment by Telichkin in "Why I hate Agile methodologies (2010)"]]></title><description><![CDATA[
<p>My current company is transforming into Agile right now, and I find this article is very good description of all these crazy stuff which happen in the company:<p>> Until today’s meeting, the friendly Agile consultant at my company has spent his time photoshopping the team leader’s face onto pictures of Yoda, and researching the motivational properties of various colours of magic marker. And he gets paid for it.</p>
]]></description><pubDate>Fri, 06 Sep 2019 08:46:52 +0000</pubDate><link>https://news.ycombinator.com/item?id=20894063</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=20894063</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=20894063</guid></item><item><title><![CDATA[Why I hate Agile methodologies (2010)]]></title><description><![CDATA[
<p>Article URL: <a href="http://anti-agile.blogspot.com/2010/06/day-1-why-i-hate-agile-methodologies.html?m=1">http://anti-agile.blogspot.com/2010/06/day-1-why-i-hate-agile-methodologies.html?m=1</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=20894000">https://news.ycombinator.com/item?id=20894000</a></p>
<p>Points: 1</p>
<p># Comments: 1</p>
]]></description><pubDate>Fri, 06 Sep 2019 08:29:59 +0000</pubDate><link>http://anti-agile.blogspot.com/2010/06/day-1-why-i-hate-agile-methodologies.html?m=1</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=20894000</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=20894000</guid></item><item><title><![CDATA[Ask HN: How has your programming style changed over time?]]></title><description><![CDATA[
<p>When did you start programming? What has changed in your programming style and why?</p>
<hr>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=20500960">https://news.ycombinator.com/item?id=20500960</a></p>
<p>Points: 3</p>
<p># Comments: 3</p>
]]></description><pubDate>Mon, 22 Jul 2019 18:43:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=20500960</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=20500960</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=20500960</guid></item><item><title><![CDATA[New comment by Telichkin in "Show HN: Own MobX in 65 lines of code"]]></title><description><![CDATA[
<p>> doesn't shoehorn OOP into an FP approach to UI<p>Functional UI is still need some sort of imperative shell [1] to manage state. You can use OOP and Remold just for "reactive" behaviour, and implement all state transitions inside object in a functional way. For example:<p><pre><code>    // Pure function
    const addProduct = (order, product) => ({
        total: order.total + product.price,
    });
    
    // Imperative state
    class Order extends Remold {
        state = {
            total: 0
        };        

        @act setState(newState) { this.state = newState; }

        addProduct(p) { this.setState(addProduct(this.state, p)); }
    }

</code></pre>
> What are the advantages of this solution over features already in React (no need of Redux) such as context and the reduce hook?<p>From the React Documentation about Context feature [2]:<p>> Apply it sparingly because it makes component reuse more difficult.<p>With Remold you don't have any problems with component's reusability. You just attach pure component to an object and "connect" object's state into component's props:<p><pre><code>    // Pure component
    const OrderWidget = ({ total }) => <div class="widget">{total}</div>;
    
    // Pure function
    const addProduct = (order, product) => ({
        total: order.total + product.price,
    });
    
    // Imperative state
    class Order extends Remold {
        state = {
            total: 0
        };        

        @act setState(newState) { this.state = newState; }

        addProduct(p) { this.setState(addProduct(this.state, p)); }
        
        @mold(OrderWidget) asWidget() { return { total: this.state.total }; }
    }

</code></pre>
[1] <a href="https://www.destroyallsoftware.com/talks/boundaries" rel="nofollow">https://www.destroyallsoftware.com/talks/boundaries</a><p>[2] <a href="https://reactjs.org/docs/context.html?no-cache=1#before-you-use-context" rel="nofollow">https://reactjs.org/docs/context.html?no-cache=1#before-you-...</a></p>
]]></description><pubDate>Sun, 28 Apr 2019 22:05:54 +0000</pubDate><link>https://news.ycombinator.com/item?id=19774014</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=19774014</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=19774014</guid></item><item><title><![CDATA[New comment by Telichkin in "Show HN: Own MobX in 65 lines of code"]]></title><description><![CDATA[
<p>When I started a new React-project at my work, I asked myself: "Why do I need any external dependencies for state management such as Redux or MobX? What functionality from this dependencies do I need in the first place?".<p>I realised that I just want to have many views connected to one dataset, and I want to re-render all connected views when dataset was changed. This is a simple pub-sub pattern which everyone can implement himself. So, I implemented it myself in just 65 lines of code. I use this solution in production for 6 months and don't see any drawbacks.<p>What are the advantages of Redux or MobX over this solution?</p>
]]></description><pubDate>Sun, 28 Apr 2019 10:55:16 +0000</pubDate><link>https://news.ycombinator.com/item?id=19770424</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=19770424</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=19770424</guid></item><item><title><![CDATA[Show HN: Own MobX in 65 lines of code]]></title><description><![CDATA[
<p>Article URL: <a href="https://github.com/Telichkin/remold">https://github.com/Telichkin/remold</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=19770423">https://news.ycombinator.com/item?id=19770423</a></p>
<p>Points: 12</p>
<p># Comments: 5</p>
]]></description><pubDate>Sun, 28 Apr 2019 10:55:10 +0000</pubDate><link>https://github.com/Telichkin/remold</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=19770423</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=19770423</guid></item><item><title><![CDATA[Ask HN: I tired of web development. Should I move back to SDET?]]></title><description><![CDATA[
<p>I started my career as a Performance QA Engineer in a game development company. In Performance QA Team we were developing all kind of useful internal tools: log collectors and analyzers, reporting system, test management system, but I left the company because I wanted to be a "real" developer who's shipping a "real" product for end users. So I moved to web-development.<p>I've read "Code Complete", "Clean Code", "Extreme Programming Explained" and thought that "real" developers solve interesting problems and write maintainable and high-quality code covered by unit tests. I was wrong.<p>"Real" development and "real" products are crap. When you develop an internal tool you do it because of necessity. In contrast, when you develop a new feature for a "real" product you do it because of a manager's whim. After two years in web development and after reading HN I conclude that "real" development almost always goes together with inadequate deadlines, shitty requirements, and high level of stress. I'm one step away from burning out.<p>I want to change something in my career. Should I move back to Automation QA/Programming of Internal Tools? Have you had the same problem in your career and what decisions have you made?</p>
<hr>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=19708875">https://news.ycombinator.com/item?id=19708875</a></p>
<p>Points: 1</p>
<p># Comments: 2</p>
]]></description><pubDate>Sat, 20 Apr 2019 21:04:58 +0000</pubDate><link>https://news.ycombinator.com/item?id=19708875</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=19708875</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=19708875</guid></item><item><title><![CDATA[More Bugs Fixed in Every Release]]></title><description><![CDATA[
<p>Article URL: <a href="http://thecodist.com/article/more_bugs_fixed">http://thecodist.com/article/more_bugs_fixed</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=19681114">https://news.ycombinator.com/item?id=19681114</a></p>
<p>Points: 1</p>
<p># Comments: 0</p>
]]></description><pubDate>Wed, 17 Apr 2019 09:47:10 +0000</pubDate><link>http://thecodist.com/article/more_bugs_fixed</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=19681114</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=19681114</guid></item><item><title><![CDATA[New comment by Telichkin in "Show HN: Learn React fundamentals"]]></title><description><![CDATA[
<p>Totally agree with you. React is just an API which enhances vanilla JavaScript. In React it's possible to use all prior knowledge and practices from other languages, eg functions/objects composition, and decoration.<p>Vue is different. With it, you can't confidently use your previous programming experience.</p>
]]></description><pubDate>Fri, 01 Feb 2019 07:27:53 +0000</pubDate><link>https://news.ycombinator.com/item?id=19052316</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=19052316</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=19052316</guid></item><item><title><![CDATA[Responsive Upscaling (2015)]]></title><description><![CDATA[
<p>Article URL: <a href="https://www.smashingmagazine.com/2015/08/responsive-upscaling-large-screen-e-commerce-design/">https://www.smashingmagazine.com/2015/08/responsive-upscaling-large-screen-e-commerce-design/</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=18959957">https://news.ycombinator.com/item?id=18959957</a></p>
<p>Points: 1</p>
<p># Comments: 0</p>
]]></description><pubDate>Mon, 21 Jan 2019 12:41:33 +0000</pubDate><link>https://www.smashingmagazine.com/2015/08/responsive-upscaling-large-screen-e-commerce-design/</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=18959957</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=18959957</guid></item><item><title><![CDATA[New comment by Telichkin in "Ask HN: Go-to web stack today?"]]></title><description><![CDATA[
<p>You can do what you want just in 17 lines of pure JavaScript. This is an example:<p><pre><code>  const

  create_store = ({state, actions}) => {
    const

    after_update_do = [],

    subscribe = fn => after_update_do.push(fn),

    notify = () => after_update_do.forEach(fn => fn(state)),

    create_action = action => (...args) => {
      state = action(state, ...args);
      notify()
    };

    return Object.entries(actions).reduce((bound_actions, [action_name, action]) => 
      Object.assign({}, bound_actions, {[action_name]: create_action(action)}), 
      {subscribe})
  },

  counter = create_store({
    state: 0,
    actions: {
      increase: state => state + 1,
      
      decrease: state => state - 1,

      multiply_add: (state, a, b) => state * a + b,
    },
  });

  counter.subscribe(state => console.log('First reactive component was updated with: ' + state));
  counter.subscribe(state => console.log('Second reactive component was updated with: ' + state));

</code></pre>
Now you can call all actions directly from the counter and update all components in reactive manner.<p><pre><code>  counter.increase();
  // First reactive component was updated with: 1
  // Second reactive component was updated with: 1

  counter.multiply_add(2, 3)
  // First reactive component was updated with: 5
  // Second reactive component was updated with: 5</code></pre></p>
]]></description><pubDate>Tue, 08 Jan 2019 12:34:14 +0000</pubDate><link>https://news.ycombinator.com/item?id=18855055</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=18855055</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=18855055</guid></item><item><title><![CDATA[New comment by Telichkin in "Show HN: Technical note app that builds a knowledge base"]]></title><description><![CDATA[
<p>Sorry, but I can't understand why should I use this app instead of saving notes in a source code?</p>
]]></description><pubDate>Sun, 04 Nov 2018 19:23:10 +0000</pubDate><link>https://news.ycombinator.com/item?id=18377582</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=18377582</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=18377582</guid></item><item><title><![CDATA[New comment by Telichkin in "Confessions of a programmer: I hate code review (2010)"]]></title><description><![CDATA[
<p>Have you tried a pair programming? I realized that this practice much more effective than code review. Pair programming encourages learning inside a team, interactions and code quality. It also reduces time to market.</p>
]]></description><pubDate>Mon, 29 Oct 2018 13:51:32 +0000</pubDate><link>https://news.ycombinator.com/item?id=18327506</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=18327506</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=18327506</guid></item><item><title><![CDATA[Systems, not Programs]]></title><description><![CDATA[
<p>Article URL: <a href="https://shalabh.com/programmable-systems/systems-not-programs.html">https://shalabh.com/programmable-systems/systems-not-programs.html</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=18254214">https://news.ycombinator.com/item?id=18254214</a></p>
<p>Points: 101</p>
<p># Comments: 28</p>
]]></description><pubDate>Fri, 19 Oct 2018 04:21:12 +0000</pubDate><link>https://shalabh.com/programmable-systems/systems-not-programs.html</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=18254214</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=18254214</guid></item><item><title><![CDATA[Systems, not Programs]]></title><description><![CDATA[
<p>Article URL: <a href="https://shalabh.com/programmable-systems/systems-not-programs.html">https://shalabh.com/programmable-systems/systems-not-programs.html</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=18227705">https://news.ycombinator.com/item?id=18227705</a></p>
<p>Points: 4</p>
<p># Comments: 0</p>
]]></description><pubDate>Tue, 16 Oct 2018 08:37:06 +0000</pubDate><link>https://shalabh.com/programmable-systems/systems-not-programs.html</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=18227705</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=18227705</guid></item><item><title><![CDATA[New comment by Telichkin in "Show HN: OTP CheatSheet (Erlang)"]]></title><description><![CDATA[
<p>I'm learning Erlang right now and find that every OTP behavior has main parts in its API: client, server, possible inputs and possible outputs. But a one-dimensional structure of standard documentation (from top to bottom) can't present all these parts in one place which leads to loss of a context and longer learn-curve. That's why I create this cheat sheet to present OTP behaviors in one place using opportunities of a two-dimensional structure.</p>
]]></description><pubDate>Mon, 08 Jan 2018 00:19:56 +0000</pubDate><link>https://news.ycombinator.com/item?id=16093687</link><dc:creator>Telichkin</dc:creator><comments>https://news.ycombinator.com/item?id=16093687</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=16093687</guid></item></channel></rss>