DEV Community: Nir Lanka ニル

git diff> & apply vs stash

Nir Lanka ニル — Wed, 03 Jun 2020 10:20:25 +0000

I never use git stash and prefer to use git diff HEAD > ../diffs/whatever.diff and later git apply ../diffs/whatever.diff -3 (-3 for 3-way merge enabled).

I know a lot of people use git stash, but I'm not sure it's because they prefer it over git diff, but rather because they haven't considered it.

It could be just me, but I prefer to have my code snippets and changes to be as "tangible" as possible. Ability to back them up, add to git, reuse and all that is much more reliable and convenient with diff > apply.

What are your thoughts?

Can we support including parts of others' posts in ours to help reduce duplicate tutorial problem?

Nir Lanka ニル — Wed, 27 May 2020 08:23:21 +0000

I see a lot of similar sounding titled posts appearing in a weekly and even sometimes almost daily basis. And they sometimes rehash similar points and examples.

I realise there's a market for certain types of introduction and comparison posts, and I appreciate their writers and content. But I think it'll be effective to have a way to add to the existing content or reuse existing content (with back referrals) so that the content and contributors (writers, commenters) can build upon each other and be more efficient and valuable.

Example topics are "framework 1 vs. framework 2" and "what is this cool feature".

Are most small mobile apps just vanity projects?

Nir Lanka ニル — Mon, 25 May 2020 11:11:22 +0000

I feel that most mobile apps that come out don't have anything that's not possible to do as a web app (responsive + progressive). Of course there are a lot of apps that need to be installable apps, but I feel most small apps are apps just to be cool, and look established.

What do you think?

Killing specific node processes (*ux)

Nir Lanka ニル — Tue, 25 Feb 2020 07:39:06 +0000

Update: Instead of this post, check out this StackOverflow answer that gives a much better and convenient method of doing this by using gid (group id). It puts my method to shame

Update: For Windows, run netstat -a -n -o|findstr 8080 (or any port) in CMD, run taskkill /pid 20212 /f with that PID in place of 20212 (or show PID column in Processes tab in Task Manager, find the PID in the first command output and kill it. Kinda messy, but works.)

I had a VM hosting and running a codebase through NodeJS.

I was accessing the code through ssh in VSCode, while the code ran through a custom script inside the VM itself. It was exposed through ssh port forwarding, but that irrelevant for this story.

So, when I was switching branches, the server script tended to get frozen. I wanted to kill it and its descendants while not hurting the node processes of the VSCode server in the same VM. So I couldn't just run killall node.

To get an overall idea about the process state, I first listed down the processes with pstree | grep node. There, I could see which node processes spawned which, but without any pids.

So I ran ps aux | grep node, which gave me all the node processes with pid and other stats like memory. But it still contained VSCode server processes. So I excluded any line containing vscode: ps aux | grep node | grep -v vscode.

Voila!

Now I had the pids of each unwanted node process, but I couldn't tell which column was the pid! So I ran ps aux | head to find which column it was.

Then I killed all of them with:

kill -15 2189 2240 # ...

Here, 2189, 2240, ... are the list of pids. -15 modifier means SIGTERM.

After testing again with ps aux | grep node | grep -v vscode, I saw some processes were too frozen to respond to SIGTERM, which meant I then run kill with -9 (SIGKILL) instead of -15.

So, that's all!

Easily select h1, h2, ... through SCSS functions

Nir Lanka ニル — Mon, 20 Jan 2020 08:05:14 +0000

I was writing styles for formatting inside a rich-text web component.

There, due to limitations of the CMS and requirements, we wanted all h1, h2, ... h6 tags to have some similar presentations.

Also, we had selectors like this:

h1 + p, 
h2 + p, 
/*...*/
h6 + p { 
  /*...*/ 
}

Always writing selectors for all cases including all h# tags is a nightmare. It's hard to maintain, too. So I decided to look into how to fix this in the simplest way, while still complying to different use cases.

After going through forums and finding similar solutions, this is my end .scss code:

selector-helpers.scss:

/**
 *  Select any range in {h1, h2, h3, h4, h5, h6}.
 * 
 *  e.g. usage
 *    #{headings('', 1, 6, '.--attr')} { ... }
 */

@function headings($before:'', $from:1, $to:6, $after:'') {
    @if $from == $to {
        @return '#{$before} h#{$from}#{$after}';
    } @else {
        @return '#{$before} h#{$from}#{$after}, ' + headings($before, $from+1, $to, $after);
    }
}

Usage in x-rich-text.scss:

@import "./selector-helpers";

x-rich-text {

    // h1, ...
    #{headings()} {
        /* ... */
    }

    // h1:first-child, ...
    #{headings($after:':first-child')} {
        /* ... */
    }

    // h1 + p, ...
    #{headings($after:' + p')} {
        /* ... */
    }

    // h1, h2 (only)
    #{headings($from:1, $to:2)} {
        /* ... */
    }

    // img + p, ...
    #{headings($before:'img + ')} {
        /* ... */
    }

    // h1.--dark, h2.--dark, ...
    #{headings($after:'.--dark')} {
        /* ... */
    }

    // h1 code, h2 code, ...
    #{headings($after:' code')} {
        /* ... */
    }
}

I believe this can handle all cases with prefixes, suffixes and selective ranges in 1..6.

So yeah. :) Hope this helps you! Let me know if there's a better way of handling this.

This is why I love Git (and Vim)! (also, is there a better solution?)

Nir Lanka ニル — Fri, 17 Jan 2020 07:00:49 +0000

Today I was pushing new commits to the remote pull-request branch which already had 5 commits. Then we realized it can't be tested with functionality in our main develop branch since mine was too behind. Well, without merging from develop to my-feature.

The problem was not how to do this easily, as a simple git checkout my-feature; git merge develop; and a bit of conflict resolution before git add .; git commit should do the trick; but how to have a cleaner history. i.e. We wanted a single commit that can be tested and merged back to develop.

And to top that, we wanted to squash all 6 commits in my-feature into one, for ease of code-review.

Disclaimer: I don't like over-relying on rebase, since it can be used to change history, which is (1) dishonest, and (2) dangerous. But in this case, we had to do it.

So I got to work of fixing this issue.

Now, I'm not a great Git hacker. I do know the concepts of git and bash and try to optimize the way I do things, but I am far from being able to hack out solutions like this without looking up stuff.

So I thought how I'd manually do this.

Extract the changes
Remove branch
Add new branch
Add changes
Commit
Force push

Fun with `squash` (in Vim)

First I squashed the changes (which was redundant, as we later realize) with git rebase -i <hash-last-commit-in-develop-branch>. At the rebase edit in Vim, I wanted to replace all but the first pick commands with s or squash. I looked up and found cgn which helps replace search items. I did these steps:

Go to first line and search pick by typing /pick. Then press Enter.
Type cgn and type in the new phrase to replace the old. Then press Esc.
Press . until all the adjacent lines I need are modified.
:wq

Of course, this was totally unnecessary, since I'm using git diff later, which I didn't plan at this stage.

This is when I realized I have to delete this new squashed commit and start over! (because I would still have to merge from develop and it would create a merge commit and would be messy).

Save the changes

I'm not a huge fan of git stash. I prefer something more tangible and reliable like git diff > ./diff. Of course I may be ill-informed, but I find git stash to be pretty limited and superficial, unlike git diff.

So, to save the changes (which is now only in the current commit), I ran git diff HEAD^ HEAD > ../diffs/my-feature.diff. This dumps all the changes (file updates, creates, deletes, everything) into a text file.

Re-apply changes

Let's remove the local branch copy: git branch -D my-feature. We can force push later to replace the remote branch copy.

Now I re-created the branch new from develop:

git checkout develop
git pull
git checkout -b my-feature

Then I applied the diff back: git apply ../diffs/my-feature.diff. That hit me in the face. Hard.

... lots of lines
error: patch failed: ...
... more lines

Of course, I should've expected this. This has conflicts! Hey, wouldn't it be great if applying a git diff could work like a branch merge? Well, I was in luck, as it turned out to not just be entirely possible, but also quite simple!

git apply ../diffs/my-feature.diff -3

So simple! Just add -3. Then it applied the diff with conflicts saved the same way git merge does. All I had to do then was to resolve conflicts, add, commit everything, and do git push origin my-feature --force.

That was all!

So why do I love Git and Vim, again?

Well, it's the crazy simplicity. Everything in Git can be represented as text. And everything, no matter how separate they seem, follow the same rules. Look at how git diff can work similar to git merge! They are completely different areas!

Also, Vim. I love Sublime Text. I use it for quick advanced text-edits. I love its multi-cursor functionality. It's crazy. But Vim doesn't need a multi-cursor functionality! Instead, it makes the whole process simpler and more extensible! No limitations of simple GUI apps. You can do so much more with very little knowledge and concepts!

Bonus: my git aliases

~/.gitconfig - [alias] -

co = checkouti
br = branch
ci = commit
cm = commit -m
a = add
st = status
unstage = reset HEAD --
last = log -1 HEAD
visual = !gitk
stage = add
df = diff
rb = rebase
undo = reset HEAD~1
redo = reset \"HEAD@{1}\"
amend = commit --amend

I got these aliases from somewhere that I can't find right now. Sorry about not crediting the original writer. Thanks!

Thanks for reading through this ramble! I hope it had some exciting new stuff that would help you. I may have been silly in how I did this, in which case I'd love to hear about how you'd solve it. :)

Will Svelte ever beat the giants?

Nir Lanka ニル — Mon, 23 Dec 2019 10:45:37 +0000

If you haven't already come across Svelte, it's a new web framework/compiler that's gaining attention due to it's radically new -yet simple- approach to handling front-end data changes.

`whoami`

I have worked for almost 9 years with multiple web technologies including vanilla Javascript, jQuery, AngularJS, Angular, Ionic Stencil and React. For a few years, I've been using the two big (pun intended) frameworks: Angular and React.

Angular, React, and their popularity

Angular is backed by Google, while React is backed by Facebook.

While they provide really great tools in app development with a lot of ground-breaking usability approaches and some inspired behind-the-scenes engineering, I see the major reason for their current popularity as the reputation of their parent companies and the extensive marketing done by them.

Svelte

I believe it's hard to deny how much Svelte changes the game from a technical point of view. It solves some of the largest baggage that comes with the big frameworks: performance, delivery size, complex reactivity, and less boilerplate.

The way Svelte solves these issues is extremely simple and elegant:

Whereas traditional frameworks [...] do the bulk of their work in the browser, Svelte shifts that work into a compile step that happens when you build your app.
(svelte.dev)

That's it.

To read more about how Svelte is truly "reactive", read this article by Ovie Okeh on LogRocket.

Perks of being a compiler

By not being a framework but a compiler, Svelte is able to do something that makes developers happy: get rid of boilerplate code. Instead of using decorators, hooks or setState() methods, developers using Svelte can just assign to variables and expect the changes to be recognized.

Svelte uses valid Javascript, but makes smart code additions to enable reactivity.

Why Svelte is David to the two big Goliaths

(Is it Goliaths? or Goliathes? Golii?)

Svelte is getting a lot of recognition and generating interest among the front-end developer community. But the adoption rate is still relatively low, as expected of any newcomer front-end technology. It happened before, as seen with Vue, and will happen in the future too.

However, Svelte's background is not the same as that of Vue's, at least not yet, in terms of "backing", or "killer projects" that really exposed it to the world.

Svelte was mostly developed somewhat "under the radar", and the world only really started to see its impact by the release of version 3, which made a lot of visible and effective improvements.

My observation has been that a lot of experienced engineers are really excited about Svelte and have begun using it for new projects whenever they have control over the choice of technology. It's a good trend because of the knowledge and experience of these people that solidifies the trust in anyone observing this.

No matter the apparent advantages in developer happiness, lower cognitive overload as well as tangible advantages like time to market and performance, enterprise customers and new-comer developers are yet to discover Svelte's beauty.

Enterprises are yet to find an incentive to use a technology without it being time-tested, backed and supported by other enterprises. This is not a problem for Angular and React due to their high-profit parent companies.

On the other hand, new developers tend to go for the most popular technologies. Their incentive is the position of that technology in the job market and its stability.

So, what'll happen?

I don't think Svelte is just another hype. It may not fit all kinds of requirements other big frameworks help solve, but it seems to be very good at solving issues in the simplest and most elegant-yet-obvious ways, at the same time being as less intrusive as possible.

I'm quite optimistic about Svelte's future. I believe it will be much more popular in the future. While it's hard to say if it would beat any of the big two: they may have a lot of problems, but the amount of professional fixes and updates, as well as the community support is very hard to beat without the backing of a successful company.

I don't think Svelte will always be what it is today. It probably will head in new and exciting directions that we never thought of; because innovation is in its blood.