This is an amazing opportunity. It has getting me think a lot about what I do (I am still trying to figure out exactly what I do myself) and why I love some aspect of what I do so much, with passion. I think it boils down to the fact that I get chance to meet and collaborate with so many talented and smart people.
My family and I got here this weekend and it is HOT.
Anyway, if you are by any chance living in Japan and see this before next Monday, love to see you. Come join us!
Here is the copy of session description in Japanese.
Speaking of unicode, I also love the idea of Google Noto Fonts. Love the name. The white block that you see when unicode character is nicknamed “Tofu” and by using this fonts, cached around the world near you, there will be no-tofu. Love it.
Github pages are amazing. Best thing ever. Well, second best thing after git, anyway.
All you need to do is:
python -m SimpleHTTPServer 8088
then you can access http://localhost:8088. Nice.
I am constantly running vagrant machines, so usually port 8080 is taken. Being able to specify port like that is actually really cool.
Also, I’ve been posting links that I liked at my tumblr blog. Here are few weeks worth of links:
Bocoup’s OpenVis conference is by far my favorite conference of all time. I was only able to go one day in 2014, but I participated fully in 2013 and 2015, and I’ve loved every session. Before I forget (which I did last year…) I am going to write down/copy over my notes here.
I started making websites in 1998. Gosh, in the internet years, that’s a forever ago. Remember Perl CGI and its cgi-bin folders? I have also written a lot of website using php along the way, and LAMP stack was sort of my thing for a while. But since I started to focus every efforts on front-end stuff, it have been a while since I looked at simple backends. Some of the sites that I created long ago desparaetly needs some updates. I have, in the past, thought or looked into converting sites to ruby on rails at one point, then looked into python, then thought hard about switching to some kind of static site generator engines (like jekyll or assemble.io), and finally more recently, thought about converting them to MEAN stack. But, really, who has time for that? Lately, I am thinking about just upping my php level and “patcing” it right in php5. Or at least keep the database structure and convert the backends to be more like API or services, still using php.
This weekend, I have been sort of playing with one of my old project: Softball Stats, written by David Carlo. It is an awesome little project.
“SoftballStats is a collection of PHP4 scripts and a MySQL database that track the stats, games, players, and every play made in multiple softball/baseball seasons. SoftballStats also compiles statistics for each player.”
I could use this on my work co-ed softball team, or also use it for my son’s summer league. I started updating it on my github.
Git is just amazing. Learning command line git is one of the best thing that has happen to me. I’ve been lucky to work with some talented guys from bocoup, and I’ve gotten to know quite a bit about it lately and just wanted to document things that I do when I encounter that dreaded (well, not THAT bad) “We can’t automatically merge this pull request.” message.
Also if you have not seen this Cheat Sheet do yourself a favor and take a look.
So, pull request can’t be merged. It’s because what you worked on (likely your branch) have some conflicts with what you are trying to merge, likely origin/master. this stack overflow answer was useful in understanding what I am doing.
My instinct was to git pull. But that is a bad idea (Quick! git reset origin/your-working-branch --hard to get what you have pushed to github!). When you encounter “can’t merge” message, git’s help suggest this:
Step 1: From your project repository, bring in the changes and test.
git fetch origin
git checkout -b your-working-branch origin/your-working-branch
git merge master
fetch then merge is much better than pull. Pull does too much under the hood (as my co-worker Tim says “too much magic”). But still, chance is that you may end up with WAAAAY too many conflicts and therefore very hard to resolve them. Perhaps there is even better idea:
git fetch --all (You may not have to do –all, but I am paranoid and this is my feels safe blanket, if you know what I mean. It’ll ensure you have the latest remotes.)
then git rebase origin/master
Ah, rebase. I had sort of hard time understanding concept of rebase, but perhaps git’s message explained it to me the best. It says “First, rewinding head to replay your work on top of it…” All your commits are “replayed” after changes that are already in master. People used words like “flattening the history” when explaining rebase, which was confusing to me. but “replay your work on top” explanation worked best for me.
When you rebase, or “replay your work on top,” you resolve conflict one by one, as it encounters conflict.
You may get a message like this:
Applying: My commit 1.
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
CONFLICT (content): Merge conflict in source/js/folder/file.js
CONFLICT (content): Merge conflict in source/js/file.js
Failed to merge in the changes.
Patch failed at 0002 My commit 1.
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
Nice to have that –abort option. Unlike merge or pull, you can just forget about the whole thing. Continue till you are done.
But because rebase changes the history, you may get message like this.
Your branch and 'origin/your-working-branch' have diverged,
and have 95 and 2 different commits each, respectively.
(use "git pull" to merge the remote branch into yours)
If you push force that message will go away git push origin your-working-branch --force
$ git push origin your-working-branch -f
Counting objects: 51, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (13/13), 1.56 KiB | 0 bytes/s, done.
Total 13 (delta 8), reused 0 (delta 0)
+ 368da98...4266772 your-working-branch -> your-working-branch (forced update)
When you push force you’ll see the previous sha and the new one, so if you mess up and want to revert, simply reset hard on that previous sha and push force again
they look like previous_sha…new_sha
so in this case git reset 368da98 --hard
In case of “Oh Crap, I made a spelling mistake and I just pushed that.”
You could git reset HEAD~1 -- soft to undo last commit and re do it, OR,
change the file, then git commit --amend
Either way, since you already “Pushed” you need to push –force to make it work.
If your working directory is dirty (meaning you have conflicts) and you don’t have any work you need to save:
# Cleans the working directory.
git reset HEAD –hard
# Reset the branch to the remote (in this case your-working-branch.
git reset origin/your-working-branch –hard
Good people at Bocoup puts out this kick-butt conference in Boston every year. I am lucky to have participated in both of those years.
I’ve been posting links that I liked at Posterous (RIP) and then my tumblr blog. Here are the week worth of Articles that I liked: Friday, May 9, 2014: