菊与刀

Software engineers and developers are fortunate when they land an ideal job and settle into a company they enjoy, drawing a comfortable pay packet for interesting work. However, it’s also quite common that during our spare time, we may ask ourselves a question: what should we do to help our career development? Sooner or later, this question appears in every software engineering professional’s mind.</p>

Today, let’s talk about what we should do when we do not intend to look for a job and change our current career life immediately. Most of the ideas come from the book Land the Tech Job You Love</a>.</p>

1. Teaching your knowledge to other people</h3>
Teaching and sharing are always excellent ways to improve your learning and make your knowledge base more solid. When trying to teach a concept to others, you need to gain your audience’s interest in what you’re talking about. It would be best if you had a clear understanding of where the concept is in the big picture, and you have to figure out how to let a newbie get their hands dirty without getting too confused and losing interest.</p>
An audience may come up with questions that you never thought of. You should be prepared to answer them with as much scope as you’re familiar with, or have a friendly discussion and learn something new yourself.</p>
Sharing your knowledge with the community could also help you expand your social network and amplify your influence, which can show its worth in the future.</p>
2. Starting a blog</h3>
It sounds cool, and it is cool, to have a place people can find when they look for you on the Internet. Since a resume can only be one page long, filled with your education and job experience, what you can show to potential future employers is quite limited. But imagine that when people are easily linked to your blog (after you’ve done some SEO) and can go through your thinking by reading the recent 3-5 posts, they can gain much more insight about you.</p>
Of course, here we’re talking about a tech-related blog that deals with what value you can offer an employer. We can blog about anything that we might tell a techie buddy about at lunch or over beers after work. There are plenty of discussions online about how to build an excellent tech blog. Another book Technical Blogging, Second Edition</a> can be a step-by-step guide to plan, create, maintain, and promote a successful blog as a developer.</p>
3. Learning new things, and writing them down</h3>
Any software engineer or technical professional is in an industry that is continuously innovating and frequently adding new features and capabilities to the world around us. If you’re not learning something new, you’re falling behind the competition, or at least feeling that you have.</p>
However, there are numerous things to learn in the IT industry whose resources can be very easily accessed. It’s just a matter of whether you have the willingness to learn or not (sounds like another cliche). But here I’d like to mention that another step is quite essential: share what you’ve learned. By writing down or doing some tech sharing, what you’ve learned can become what you know. The new knowledge I mention here can be:</p>

A new programming language</li>
A new framework in the language you’re familiar with</li>
A new OS</li>
New hardware made for programming</li>
Other companies’ best practice</li>
Even another industry radically different from what we know, but which shares similarities with our industry and can teach us some lessons</li> </ul>
Whatever you’ve absorbed can be transformed into new knowledge that may be beneficial to yourself and innovative to other colleagues. Continually investing in learning and sharing what you’ve learned pays much bigger dividends.</p>
4. Updating your resume every three months</h3>
Add ‘update my resume’ into your calendar and set the interval as every three months. Almost whenever we open the resume after some time, we can find things to add in or to improve on. It could be a job promotion (congrats!), or it could be a new job responsibility or a new project that your team is now working on. It can also be something not done in your office, but an open-source project you are actively contributing to. Whatever adds value to your company and yourself should be added to your resume.</p>
If you cannot find anything worth adding to your resume for six months or so, treat it as a warning. Your career progress has probably stalled, and your skills may be going rusty. It is a good moment to consider looking for more challenges, maybe by switching jobs, or by proactively seeking new challenges and taking on more responsibilities. As the book Land the Tech Job You Love</a> says, “Lather, rinse, repeat.”</p>
5. Growing your network and jumping out of your comfort zone</h3>
It is all too familiar: software engineers spend at least 70% of their time in an IDE and would rather not spend effort talking to people. Some developers are not keen to communicate and feel more comfortable letting the code talk. That said, maintaining a reliable professional network can matter as much as any other area of self-improvement (like sections 1-4 above). You might have the best skills, but they’re not much good if your ideal employers can’t easily find that out.</p>
Here are some handy tips we can take up gradually, starting next Monday when we walk into the office.</p>

Have lunch with people outside your team, and get to know them</li>
Join the office’s interest group, and break the invisible wall between engineers and non-engineers</li>
Join a local tech community in your area of expertise, like GraphQL Singapore</a></li>
Join user groups in areas you’re not familiar with but would like to learn about</li>
Keep track of your connections’ updates, and stay updated about their vital information</li> </ol>
5 questions for self-checking</h3>

As technical professionals, we are blessed to have the skills to be well paid for jobs that we love. Not just like, but love. Please don’t settle for anything less.</p> </blockquote>
Here are five questions that a software engineer or IT professional can ask themselves regularly.</p>

Is my resume up-to-date?</li>
Am I competitive in the current job market?</li>
Am I able to be found online with an insightful presence?</li>
Do I have at least five people to approach when I’m seeking help to find my next job?</li>
Do I have at least three references who can speak for my work experience and ability?</li> </ol>
Recommended books for software engineer career development</h5>

Land the Tech Job You Love</a></li>
Technical Blogging, Second Edition</a></li>
The Pragmatic Programmer, 20th Anniversary Edition</a></li> </ol>

Some pragmatic notes for programmers (part 2)

Unknown — Sun, 15 Dec 2019 00:00:00 +0000

Extracted some interesting points from the book “The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition”</a>.</p>

7. While You Are Coding</h2>

Perhaps there’s an element of imposter syndrome, too; we may think that this project is beyond us. We can’t see our way through to the end; we’ll get so far and then be forced to admit that we’re lost.</li>
If that’s not working, try externalizing the issue. Make doodles about the code you’re writing, or explain it to a coworker (preferably one who isn’t a programmer), or to your rubber duck. Expose different parts of your brain to the issue, and see if any of them have a better handle on the thing that’s troubling you. We’ve lost track of the number of conversations we’ve had where one of us was explaining a problem to the other and suddenly went “Oh! Of course!” and broke off to fix it.</li>
We should avoid programming by coincidence—relying on luck and accidental successes—in favor of programming deliberately.</li>
For code you write that others will call, the basic principles of good modularization and of hiding implementation behind small, well-documented interfaces can all help. A well-specified contract (see Topic 23, Design by Contract) can help eliminate misunderstandings.</li>
Don’t code in the dark. Build an application you don’t fully grasp, or use a technology you don’t understand, and you’ll likely be bitten by coincidences. If you’re not sure why it works, you won’t know why it fails.</li>
Rely only on reliable things. Don’t depend on assumptions. If you can’t tell if something is reliable, assume the worst.</li>
Don’t be a slave to history. Don’t let existing code dictate future code. All code can be replaced if it is no longer appropriate. Even within one program, don’t let what you’ve already done constrain what you do next—be ready to refactor (see Topic 40, Refactoring). This decision may impact the project schedule. The assumption is that the impact will be less than the cost of not making the change.</li>
You refactor when you’ve learned something; when you understand something better than you did last year, yesterday, or even just ten minutes ago.</li>
In order to guarantee that the external behavior hasn’t changed, you need good, automated unit testing that validates the behavior of the code.</li>
Don’t try to refactor and add functionality at the same time.</li>
Make sure you have good tests before you begin refactoring. Run the tests as often as possible. That way you will know quickly if your changes have broken anything.</li>
Testing Is Not About Finding Bugs.</li>
We strongly believe that the only way to build software is incrementally. Build small pieces of end-to-end functionality, learning about the problem as you go.</li>
A culture of testing means all the tests pass all the time. Ignore a spew of tests that “always fail” makes it easier to ignore all the tests, and the vicious spiral begins.</li>
Make no mistake, testing is part of programming. It’s not something left to other departments or staff. Testing, design, coding—it’s all programming.</li> </ol>
8. Before the Project</h2>

No One Knows Exactly What They Want.</li>
whenever you create something, you need to pause and think “what is my motivation to create this?”.</li>
Requirements rarely lie on the surface. Normally, they’re buried deep beneath layers of assumptions, misconceptions, and politics. Even worse, often they don’t really exist at all.</li>
Programmers Help People Understand What They Want.</li>
This is both an intellectual process and a creative one: you’re thinking on your feet and you’re contributing to a solution that is likely to be better than one that either you or the client would have produced alone.</li>
Requirements are not architecture. Requirements are not design, nor are they the user interface. Requirements are need.</li>
Create and maintain a project glossary—one place that defines all the specific terms and vocabulary used in a project.</li>
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.</li>
Having a second developer’s full brain available during the task brings a lot more mental power to bear.</li>
Build the code, not your ego. It’s not about who’s brightest; we all have our moments, good and bad.</li>
Criticise the code, not the person. “Let’s look at this block” sounds much better than “you’re wrong.”</li>
Listen and try to understand others’ viewpoints. Different isn’t wrong.</li>
Conduct frequent retrospectives to try and improve for next time.</li>
Don’t Go into the Code Alone</li>
Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation.Responding to change over following a plan.</li> </ol>
9. Pragmatic Projects</h2>

Programmers are a bit like cats: intelligent, strong willed, opinionated, independent, and often worshiped by the net.</li>
Stay awake and aware for increased scope, decreased time scales, additional features, new environments—anything that wasn’t in the original understanding. Keep metrics on new requirements.</li>
Great project teams have a distinct personality. People look forward to meetings with them, because they know that they’ll see a well-prepared performance that makes everyone feel good.</li>
Maintain awareness to stay DRY.</li>
Does it work well for you? Or was it adopted just because it was being used by the latest internet-fueled success story?</li>
Do What Works, Not What’s Fashionable</li>
the idea of the Pragmatic Starter Kit was born, covering these three critical and interrelated topics: Version Control, Regression Testing, Full Automation.</li>
You deliver when the users need it, when it makes business sense to do so.</li>
Pragmatic Programmers are different. We are driven to find our bugs now, so we don’t have to endure the shame of others finding our bugs later.</li>
Test Early, Test Often, Test Automatically</li>
In fact, a good project may well have more test code than production code. The time it takes to produce this test code is worth the effort. It ends up being much cheaper in the long run, and you actually stand a chance of producing a product with close to zero defects.</li>
A bug-free system that answers the wrong question isn’t very useful.</li>
But it’s these expectations of business value that really count—not just the software project itself. The software is only a means to these ends.</li>
Even though your title might be some variation of “Software Developer” or “Software Engineer,” in truth it should be “Problem Solver.” That’s what we do, and that’s the essence of a Pragmatic Programmer.</li>
The Golden Rule (“Do unto others as you would have them do unto you’’) and a foundation of mutual respect among the developers is critical to make this tip work.</li>
It’s Your Life. Share it. Celebrate it. Build it. AND HAVE FUN!</li> </ol>

Some pragmatic notes for programmers (part 1)

Unknown — Sun, 08 Dec 2019 00:00:00 +0000

Keep a record of some highlights from the book “The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition”</a> which might be useful to me, or to your Software Engineer career path.</p>

What makes a pragmatic programmer?</h3>

Over the long term, your time investment will be repaid as you and your team become more efficient, write code that’s easier to maintain, and spend less time in meetings.</li>
You rarely take things as given without first getting the facts. When colleagues say “because that’s the way it’s done,” or a vendor promises the solution to all your problems, you smell a challenge.</li>
We who cut mere stones must always be envisioning cathedrals.</strong></li>
Every day, work to refine the skills you have and to add new tools to your repertoire.</li> </ol>
1. A Pragmatic Philosophy && Software Entropy</h3>

When you find yourself saying, “I don’t know,” be sure to follow it up with “—but I’ll find out.” It’s a great way to admit what you don’t know, but then take responsibility like a pro.</li>
Before you approach anyone to tell them why something can’t be done, is late, or is broken, stop and listen to yourself. Talk to the rubber duck on your monitor, or the cat.</li>
Don’t leave “broken windows’’ (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up.</strong></li>
It’s time to bring out the stones. Work out what you can reasonably ask for. Develop it well. Once you’ve got it, show people, and let them marvel. Then say “of course, it would be better if we added…’’ Pretend it’s not important. Sit back and wait for them to start asking you to add the functionality you originally wanted. People find it easier to join an ongoing success. Show them a glimpse of the future and you’ll get them to rally around.</li>
If you give your users something to play with early, their feedback will often lead you to a better eventual solution.</li>
Talking to other people will help build your personal network, and you may surprise yourself by finding solutions to other, unrelated problems along the way. And that old portfolio just keeps getting bigger.</li>
The more different things you know, the more valuable you are.</strong></li>
Know what you want to say. Know your audience. Choose your moment. Choose a style. Make it look good. Involve your audience. Be a listener. Get back to people. Keep code and documentation together.</li>
if you don’t listen to them, they won’t listen to you.</strong></li>
Treat English (or whatever your native tongue may be) as just another programming language. Write natural language as you would write code: honor the DRY principle, ETC, automation, and so on.</li>
A good idea is an orphan without effective communication.</li> </ol>
2. A Pragmatic Approach</h3>

In the modern world, it’s critical to test ideas and get feedback before you commit to them whole-heartedly.</li>
We feel that the only way to develop software reliably, and to make our developments easier to understand and maintain, is to follow what we call the DRY principle: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.</strong></li>
Don’t rely on the properties of things you can’t control.</li>
Requirements, users, and hardware change faster than we can get the software developed.</li>
The distinction is important enough to warrant repeating. Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system. Think of prototyping as the reconnaissance and intelligence gathering that takes place before a single tracer bullet is fired.</li>
Our suggestion is fairly simple: don’t spend more effort than you save. Writing a domain language adds some cost to your project, and you’ll need to be convinced that there are offsetting savings (potentially in the long term).</li>
Use paper, not a file or a wiki: there’s something special about the act of writing compared to typing. Give it a month, and see if you’re getting any benefits.</li> </ol>
3. Pragmatic Paranoia</h3>

But Pragmatic Programmers take this a step further. They don’t trust themselves, either. Knowing that no one writes perfect code, including themselves, Pragmatic Programmers build in defenses against their own mistakes.</li>
The finish what you start tip tells us that, ideally, the routine that allocates a resource should also free it.</li>
Much of the time, tomorrow looks a lot like today. But don’t count on it.</li>
Let’s look at four strategies that help.</li>
Finite State Machines</li>
The Observer Pattern</li>
Publish/Subscribe</li>
Reactive Programming and Streams</li>
Let us suggest three techniques that mean you should never need to use inheritance again:</li>
Interfaces and protocols</li>
Delegation</li>
Mixins and traits</li>
We still want configuration data kept external to the application, but rather than in a flat file or database, we’d like to see it stored behind a service API. This has a number of benefits:</li>
Multiple applications can share configuration information, with authentication and access control limiting what each can see</li>
Configuration changes can be made globally</li>
The configuration data can be maintained via a specialized UI</li>
The configuration data becomes dynamic</li> </ol>

Some LeetCode Contest in Rust

Unknown — Sat, 26 Oct 2019 00:00:00 +0000

As I’m learning Rust recently, LeetCode has become a good place to write small programs and to get familiar with Rust grammar and syntax. In the recent two contests, I tried using Rust to solve some problems; however, it took much longer than I expected to deal with the strict compiler. Pretty fun though, and I think it did help me get my hands dirty.</p>

However, personally I won’t suggest using Rust in LeetCode contests or in real interviews as Python/Ruby would be a much better choice. Rust could be useful in some other aspects which I’ll check later. (safety, speed, and concurrency? + WebAssembly)</p>

1234. Replace the Substring for Balanced String</a></h3>

Keyword: Sliding window</strong></p>

Use a counter to keep track of the appearances outside</strong> of the sliding window, and try to make the window as small as possible.</p>

Rust solution:</p>

use</span> std</span>::</span>cmp;</span></span>
use</span> std</span>::</span>collections</span>::</span>HashMap</span>;</span></span>
</span>
struct</span> Solution</span> {}</span></span>
</span>
impl</span> Solution</span> {</span></span>
    pub fn</span> balanced_string</span>(s</span>:</span> String</span>)</span> -></span> i32</span> {</span></span>
        let mut</span> counter</span>:</span> HashMap</span><</span>char</span>,</span> i32</span>></span> =</span> HashMap</span>::</span>new</span>();</span></span>
        for</span> c</span> in</span> [</span>'Q'</span>,</span> 'W'</span>,</span> 'E'</span>,</span> 'R'</span>]</span>.</span>iter</span>() {</span></span>
            counter</span>.</span>insert</span>(</span>*</span>c,</span> 0</span>);</span></span>
        }</span></span>
        for</span> c</span> in</span> s</span>.</span>chars</span>() {</span></span>
            let</span> new_count</span> = match</span> counter</span>.</span>get</span>(</span>&</span>c) {</span></span>
                Some</span>(</span>&</span>val)</span> =></span> val</span> +</span> 1</span>,</span></span>
                None</span> =></span> 1</span>,</span></span>
            };</span></span>
            counter</span>.</span>insert</span>(c, new_count);</span></span>
        }</span></span>
        let</span> length</span> =</span> s</span>.</span>len</span>()</span> as</span> i32</span>;</span></span>
        let mut</span> result</span> =</span> length;</span></span>
        let</span> expected</span> =</span> length</span> /</span> 4</span>;</span></span>
</span>
        let</span> (</span>mut</span> j,</span> mut</span> i)</span> =</span> (</span>0_</span>i32</span>,</span> 0_</span>i32</span>);</span></span>
        while</span> j</span> <</span> length {</span></span>
            let</span> char_j</span> =</span> s</span>.</span>chars</span>()</span>.</span>nth</span>(j</span> as</span> usize</span>)</span>.</span>unwrap</span>();</span></span>
            counter</span>.</span>insert</span>(char_j, counter</span>.</span>get</span>(</span>&</span>char_j)</span>.</span>unwrap</span>()</span> -</span> 1</span>);</span></span>
</span>
            // sliding window</span></span>
            while</span> i</span> <</span> length</span></span>
                &&</span> counter[</span>&</span>'Q'</span>]</span> <=</span> expected</span></span>
                &&</span> counter[</span>&</span>'W'</span>]</span> <=</span> expected</span></span>
                &&</span> counter[</span>&</span>'E'</span>]</span> <=</span> expected</span></span>
                &&</span> counter[</span>&</span>'R'</span>]</span> <=</span> expected</span></span>
                {</span></span>
                    result</span> =</span> cmp</span>::</span>min</span>(result, j</span> -</span> i</span> +</span> 1</span>);</span></span>
</span>
                    let</span> char_i</span> =</span> s</span>.</span>chars</span>()</span>.</span>nth</span>(i</span> as</span> usize</span>)</span>.</span>unwrap</span>();</span></span>
                    counter</span>.</span>insert</span>(char_i, counter</span>.</span>get</span>(</span>&</span>char_i)</span>.</span>unwrap</span>()</span> +</span> 1</span>);</span></span>
                    i</span> +=</span> 1</span>;</span></span>
                }</span></span>
            j</span> +=</span> 1</span>;</span></span>
        }</span></span>
</span>
        result</span></span>
    }</span></span>
}</span></span>
</span>
#[cfg(test)]</span></span>
mod</span> tests</span> {</span></span>
    use</span> super</span>::*</span>;</span></span>
</span>
    #[test]</span></span>
    fn</span> test</span>() {</span></span>
        let</span> s</span> =</span> "QWER"</span>.</span>to_string</span>();</span></span>
        assert_eq!</span>(</span>Solution</span>::</span>balanced_string</span>(s),</span> 0</span>);</span></span>
</span>
        let</span> s</span> =</span> "QQWE"</span>.</span>to_string</span>();</span></span>
        assert_eq!</span>(</span>Solution</span>::</span>balanced_string</span>(s),</span> 1</span>);</span></span>
    }</span></span>
}</span></span></code></pre>
Some places in the code may be not necessary:</p>

Update a counter’s value for a character, I’m using: let char_j = s.chars().nth(j as usize).unwrap();</code> counter.insert(char_j, counter.get(&char_j).unwrap() - 1);</code> which is actually the same as counter[c] += 1</code> in Python. Seems too long in Rust.</li>
For the place while i < length && counter[&'Q'] <= expected && counter[&'W'] <= expected</code> && counter[&'E'] <= expected && counter[&'R'] <= expected</code>, it would be all([counter[x] <= expected for x in 'QWER'])</code> in Python.</li>
</ol>
1235. Maximum Profit in Job Scheduling</a></h3>
Keyword: DP</strong></p>
Use [(ending_time, max_profit)] to keep track of possible best profit for each end time. For a new job, use binary search</strong> to find the possible previous ending time for the last job, and calculate whether the profit would be better than the current best (last element in the DP record); if so, append it to the end of the DP record vector.</p>
struct</span> Solution</span>{}</span></span>
</span>
impl</span> Solution</span> {</span></span>
    pub fn</span> job_scheduling</span>(start_time</span>:</span> Vec</span><</span>i32</span>>, end_time</span>:</span> Vec</span><</span>i32</span>>, profit</span>:</span> Vec</span><</span>i32</span>>)</span> -></span> i32</span> {</span></span>
        let mut</span> jobs</span> =</span> Vec</span>::</span>new</span>();</span></span>
        let</span> length</span> =</span> start_time</span>.</span>len</span>();</span></span>
        for</span> i</span> in</span> 0</span>..</span>length {</span></span>
            jobs</span>.</span>push</span>((start_time[i], end_time[i], profit[i]))</span></span>
        }</span></span>
        jobs</span>.</span>sort_by_key</span>(</span>|</span>t1</span>|</span> t1</span>.</span>1</span>);</span></span>
</span>
        let mut</span> record</span> =</span> vec!</span>[(</span>0</span>,</span> 0</span>)];</span>  // (ending, max_profit)</span></span>
        for</span> (s, e, p)</span> in</span> jobs {</span></span>
            let</span> last_job_index</span> = match</span> record</span>.</span>binary_search_by_key</span>(</span>&</span>s,</span> |&</span>t</span>|</span> t</span>.</span>0</span>) {</span></span>
                Ok</span>(i)</span> =></span> i,</span></span>
                Err</span>(i)</span> =></span> i</span>-</span>1</span>,</span></span>
            };</span></span>
            if</span> record[last_job_index]</span>.</span>1</span> +</span> p</span> ></span> record</span>.</span>last</span>()</span>.</span>unwrap</span>()</span>.</span>1</span> {</span></span>
                record</span>.</span>push</span>((e, record[last_job_index]</span>.</span>1</span> +</span> p))</span></span>
            }</span></span>
        }</span></span>
        record</span>.</span>last</span>()</span>.</span>unwrap</span>()</span>.</span>1</span></span>
    }</span></span>
}</span></span>
</span>
#[cfg(test)]</span></span>
mod</span> tests</span> {</span></span>
    use</span> super</span>::*</span>;</span></span>
</span>
    #[test]</span></span>
    fn</span> test1 () {</span></span>
        let</span> starts</span> =</span> vec!</span>[</span>1</span>,</span>2</span>,</span>3</span>,</span>4</span>,</span>6</span>];</span></span>
        let</span> ends</span> =</span> vec!</span>[</span>3</span>,</span>5</span>,</span>10</span>,</span>6</span>,</span>9</span>];</span></span>
        let</span> profit</span> =</span> vec!</span>[</span>20</span>,</span>20</span>,</span>100</span>,</span>70</span>,</span>60</span>];</span></span>
</span>
        assert_eq!</span>(</span>Solution</span>::</span>job_scheduling</span>(starts, ends, profit),</span> 150</span>);</span></span>
    }</span></span>
}</span></span></code></pre>1223. Dice Roll Simulation</a></h3>
Keyword: Cache</strong></p>
To make it not TLE we use a cache to reduce time cost. However, in Rust, it happened to be the very first HashMap I used and cost me some time to deal with the compiler. I finally made it pass with the code below. The <'a></code> is an explicit lifetime which could be implicit.</p>
use</span> std</span>::</span>collections</span>::</span>HashMap</span>;</span></span>
</span>
// struct Solution {}</span></span>
</span>
type</span> Cache</span><'</span>a</span>></span> =</span> HashMap</span><</span>String</span>,</span> i32</span>>;</span></span>
</span>
impl</span> Solution</span> {</span></span>
    pub fn</span> die_simulator</span>(n</span>:</span> i32</span>, roll_max</span>:</span> Vec</span><</span>i32</span>>)</span> -></span> i32</span> {</span></span>
        let mut</span> cache</span>:</span> Cache</span> =</span> HashMap</span>::</span>new</span>();</span></span>
</span>
        fn</span> helper</span><'</span>a</span>>(</span></span>
            k</span>:</span> i32</span>,</span></span>
            number</span>:</span> i32</span>,</span></span>
            n</span>:</span> i32</span>,</span></span>
            roll_max</span>: &</span>Vec</span><</span>i32</span>>,</span></span>
            cache</span>: &mut</span> Cache</span><'</span>a</span>>,</span></span>
        )</span> -></span> i32</span> {</span></span>
            if</span> n</span> ==</span> 0</span> {</span></span>
                return</span> 1</span>;</span></span>
            }</span></span>
            let</span> key_string</span> =</span> format!</span>(</span>"{} {} {}"</span>, k, number, n);</span></span>
            let ref</span> key</span> =</span> key_string</span>.</span>to_string</span>();</span></span>
            match</span> cache</span>.</span>get</span>::</span><</span>str</span>>(</span>&</span>key) {</span></span>
                Some</span>(</span>&</span>number)</span> => return</span> number,</span></span>
                _</span> =></span> {}</span></span>
            }</span></span>
            let mut</span> temp</span>:</span> i64</span> =</span> 0</span>;</span></span>
            for</span> i</span> in</span> 0</span>..</span>6</span> {</span></span>
                if</span> number</span> !=</span> i {</span></span>
                    temp</span> +=</span> helper</span>(</span>1</span>, i, n</span> -</span> 1</span>, roll_max, cache)</span> as</span> i64</span>;</span></span>
                }</span> else if</span> k</span> <</span> roll_max[i</span> as</span> usize</span>] {</span></span>
                    temp</span> +=</span> helper</span>(k</span> +</span> 1</span>, i, n</span> -</span> 1</span>, roll_max, cache)</span> as</span> i64</span>;</span></span>
                }</span></span>
            }</span></span>
            let</span> result</span> =</span> (temp</span> %</span> (</span>10_</span>i64</span>.</span>pow</span>(</span>9</span>)</span> +</span> 7</span>))</span> as</span> i32</span>;</span></span>
            cache</span>.</span>insert</span>(key_string, result);</span></span>
            result</span></span>
        }</span></span>
</span>
        helper</span>(</span>0</span>,</span> 0</span>, n,</span> &</span>roll_max,</span> &mut</span> cache)</span></span>
    }</span></span>
}</span></span></code></pre>1240. Tiling a Rectangle with the Fewest Squares</a></h3>
Keyword: DP</strong></p>
It’s an interesting DP problem, as it only cares about 1<=n,m<=13</code> cases. For larger ranges, it would become very complicated; please check this link</a> for more info.</p>
Solution in Rust:</p>
use</span> std</span>::</span>cmp</span>::</span>min;</span></span>
</span>
struct</span> Solution</span> {}</span></span>
</span>
impl</span> Solution</span> {</span></span>
    pub fn</span> tiling_rectangle</span>(n</span>:</span> i32</span>, m</span>:</span> i32</span>)</span> -></span> i32</span> {</span></span>
        let mut</span> record</span> =</span> vec!</span>[</span>vec!</span>[</span>0</span>; n</span> as</span> usize</span> +</span> 1</span>]; m</span> as</span> usize</span> +</span> 1</span>];</span></span>
        record[</span>0</span>][</span>0</span>]</span> =</span> 1</span>;</span></span>
</span>
        //special case</span></span>
        if</span> (n</span> ==</span> 11</span> &&</span> m</span> ==</span> 13</span>)</span> ||</span> (n</span> ==</span> 13</span> &&</span> m</span> ==</span> 11</span>) {</span></span>
            return</span> 6</span>;</span></span>
        }</span></span>
</span>
        for</span> i</span> in</span> 0</span>..</span>m</span> as</span> usize</span> +</span> 1</span> {</span></span>
            for</span> j</span> in</span> 0</span>..</span>n</span> as</span> usize</span> +</span> 1</span> {</span></span>
                if</span> i</span> ==</span> 0</span> ||</span> j</span> ==</span> 0</span> {</span></span>
                    record[i][j]</span> =</span> 0</span>;</span></span>
                    continue</span>;</span></span>
                }</span></span>
                if</span> i</span> ==</span> j {</span></span>
                    record[i][j]</span> =</span> 1</span>;</span></span>
                    continue</span>;</span></span>
                }</span></span>
                let mut</span> temp</span> =</span> 13</span>*</span>13</span>;</span></span>
                for</span> k</span> in</span> 1</span>..=</span>min</span>(i, j) {</span></span>
                    temp</span> =</span> min</span>(temp,</span></span>
                               min</span>(</span>1</span> +</span> record[i</span>-</span>k][j]</span> +</span> record[k][j</span>-</span>k],</span> 1</span> +</span> record[i][j</span>-</span>k]</span> +</span> record[i</span>-</span>k][k])</span></span>
                    );</span></span>
                }</span></span>
                record[i][j]</span> =</span> temp;</span></span>
            }</span></span>
        }</span></span>
        *</span>record</span>.</span>last</span>()</span>.</span>unwrap</span>()</span>.</span>last</span>()</span>.</span>unwrap</span>()</span></span>
    }</span></span>
}</span></span>
</span>
#[cfg(test)]</span></span>
mod</span> tests</span> {</span></span>
    use</span> super</span>::*</span>;</span></span>
</span>
    #[test]</span></span>
    fn</span> test</span>() {</span></span>
        assert_eq!</span>(</span>Solution</span>::</span>tiling_rectangle</span>(</span>2</span>,</span> 3</span>),</span> 3</span>);</span></span>
        assert_eq!</span>(</span>Solution</span>::</span>tiling_rectangle</span>(</span>5</span>,</span> 8</span>),</span> 5</span>);</span></span>
        assert_eq!</span>(</span>Solution</span>::</span>tiling_rectangle</span>(</span>11</span>,</span> 13</span>),</span> 6</span>);</span></span>
    }</span></span>
}</span></span></code></pre>

mark@usegitflow

Write the rule, not just the fix, so Claude can follow it

How I use Superpowers for engineering work

战争与和平

What I learned from The Art of SEO

Worth reading?</h2> Yes, if you own anything on the web. Just pair it with something current on GEO, because the ground under this one is still moving.</p>

Dostoevsky’s Notes from Underground

Siddhartha by Hermann Hesse, A Short Reflection

Making Chill Lofi Music with GarageBand

Why I Like Lofi</h2> What’s not to love about lofi? It’s got these little noises, the sound of an old record, the tiny crackles, that just make you feel cozy. It’s also easy to get into: you don’t need a pile of fancy gear or to be a music genius.</p>

How I Passed the JLPT N1 Test

Think Again: the art of rethinking in both career and life

A new page in 2022

What I learned from How to Avoid a Climate Disaster

Applying CSS grid

Steps to use the Grid layout</h2> Create a Grid container by defining the size of several rows and columns. You can also let the Grid extend automatically.</li> Place the Grid lines</li> Attach elements to the Grid</li> Define the Grid flow (optional)</li> Align and justify items</li>

Useful Resources</h2> I’d like to list the resources I used along the way, for serious learners who want to learn Grid CSS thoroughly.</p>

My Japanese learning path from Zero to JLPT N3

Learning path</h3> I want to introduce my reference books, textbooks, exam books</strong>, and how I used them. I hope it can help somebody to start their journey of learning Japanese.</p> For reference books, I only bought two books, and these are more than enough for me.</p>

菊与刀

5 Things To Do For Career Development As a Software Engineer

Some pragmatic notes for programmers (part 2)

Some pragmatic notes for programmers (part 1)

Some LeetCode Contest in Rust

Leetcode Contest 154, 155 - Graph

Leetcode Contest 153

Make Array Strictly Increasing</a></h4> Given two integer arrays arr1 and arr2, return the minimum number of operations (possibly zero) needed to make arr1 strictly increasing.</p> </blockquote>

How to use Insomnia for GraphQL requests

Use cases when we work with a GraphQL endpoint</h3> Send my first request to a new GraphQL endpoint</li> Introspection query to fetch the schema</li>

Leetcode Contest 147

Stone Game II</a></h4> Alex and Lee continue their games with piles of stones. There are a number of piles arranged in a row, and each pile has a positive integer number of stones piles[i]. The objective of the game is to end with the most stones.</p> </blockquote>

GraphQL Explained

Introspection</h5> Introspection is the ability to query details about the current API’s schema. When getting to know a new GraphQL API, it is a good idea to find out what fields are available on the root types.</p>

Some notes about real world implementations</h3>

Schema first development</h4> Problems with web projects usually stem from a lack of communication or miscommunication about what should be built. Schemas provide clarity and communication, which is why many projects practice schema-first development.</p> Reference</strong>:</p>

Leetcode Contest 140

Letter Tile Possibilities</a></h4> You have a set of tiles, where each tile has one letter tiles[i] printed on it. Return the number of possible non-empty sequences of letters you can make.</p> </blockquote> Keyword: permutation</strong></p>

Smallest Subsequence of Distinct Characters</a></h4> Return the lexicographically smallest subsequence of text that contains all the distinct characters of text exactly once.</p> </blockquote> Keyword: Greedy</strong></p>

Leetcode Contest 135

沉默的大多数

《乌合之众》说了些什么？

群体的意见和信仰</h3>

群体的分类</h3>

异质群体</h4> 匿名：大街上的人 非匿名：评委，议会</p>

同质群体</h4> 宗派，等级集团，阶级</p>

群体的一般特征</h3>

群体情感和道德特征</h3>

道德特征</h4> 法不责众</li> 受本能驱使的群体可能做出有崇高道德性质的行为</li> </ol> 宗教特点</h4> 盲目服从，极其狭隘，渴望传播</li> 神化心目中的崇高者</li> 这种情感可以让群体感到幸福</li> </ol>

宗教特点</h4> 盲目服从，极其狭隘，渴望传播</li> 神化心目中的崇高者</li> 这种情感可以让群体感到幸福</li> </ol>

First post

Worth reading?</h2>
Yes, if you own anything on the web. Just pair it with something current on GEO, because the ground under this one is still moving.</p>
The Art of SEO, by Eric Enge, Stephan Spencer and Jessie C. Stricchiola. Goodreads</a>.</p>

Why I Like Lofi</h2>
What’s not to love about lofi? It’s got these little noises, the sound of an old record, the tiny crackles, that just make you feel cozy. It’s also easy to get into: you don’t need a pile of fancy gear or to be a music genius.</p>

异质群体</h4>
匿名：大街上的人非匿名：评委，议会</p>

同质群体</h4>
宗派，等级集团，阶级</p>

道德特征</h4>

法不责众</li>
受本能驱使的群体可能做出有崇高道德性质的行为</li> </ol>
宗教特点</h4>

盲目服从，极其狭隘，渴望传播</li>
神化心目中的崇高者</li>
这种情感可以让群体感到幸福</li> </ol>

宗教特点</h4>

盲目服从，极其狭隘，渴望传播</li>
神化心目中的崇高者</li>
这种情感可以让群体感到幸福</li> </ol>