Skip to content

Latest commit

 

History

History
165 lines (135 loc) · 12.9 KB

dailynote.2019.org

File metadata and controls

165 lines (135 loc) · 12.9 KB

时光飞逝

关于compiler的

https://bernsteinbear.com/blog/bytecode-interpreters/ https://news.ycombinator.com/item?id=18821475 这里也提到刚刚看完的 Writing a compiler in go这本书。

http://karpathy.github.io/neuralnets/ https://hn.academy/ 机器学习相关

how to ask questions

A good question is energizing. It’s an inviting challenge, it’s something that’s interesting and fun to pursue. It inspires a new way of seeing things, a new way of ordering information.

A good question is an act of pointing. First you survey the ideascape in front of you – maybe it’s shared territory between the two of you, or maybe it’s you looking over your conversation-partner’s shoulder – and then you try and identify the most compelling, interesting thing, and point to that.

“Funny” or “interesting” is a sort of compass or gyroscope that guides you away from stale questions.

Like almost all problems in life you have only 4 options: #1 Change you (accept what you are unable to change)

#2 Change the other (convince them to follow your vision)

#3 Fly (divorce, quit)

#4 Stay and suffer (include drinking, doing drugs, whining)

It is amazing how many people chose number 4.

(1) Start a freelance practice. (2) Raise your rates.

(3) As you work for clients, keep a sharp eye for opportunities to build “specialty practices”. If you get to work on a project involving Mongodb, spend some extra time and effort to get Mongodb under your belt. If you get a project for a law firm, spend some extra time thinking about how to develop applications that deal with contracts or boilerplates or PDF generation or document management.

(4) Raise your rates.

(5) Start refusing hourly-rate projects. Your new minimum billable increment is a day.

(6) Take end-to-end responsibility for the business objectives of whatever you build. This sounds fuzzy, like, “be able to talk in a board room”, but it isn’t! It’s mechanically simple and you can do it immediately: Stop counting hours and days. Stop pushing back when your client changes scope. Your remedy for clients who abuse your flexibility with regards to scope is “stop working with that client”. Some of your best clients will be abusive and you won’t have that remedy. Oh well! Note: you are now a consultant.

(7) Hire one person at a reasonable salary. You are now responsible for their payroll and benefits. If you don’t book enough work to pay both your take-home and their salary, you don’t eat. In return: they don’t get an automatic percentage of all the revenue of the company, nor does their salary automatically scale with your bill rate.

(8) You are now “senior” or “principal”. Raise your rates.

(9) Generalize out from your specialties: Mongodb -> NoSQL -> highly scalable backends. Document management -> secure contract management.

(10) Raise your rates.

(11) You are now a top-tier consulting group compared to most of the market. Market yourself as such. Also: your rates are too low by probably about 40-60%.

Try to get it through your head: people who can simultaneously (a) crank out code (or arrange to have code cranked out) and (b) take responsibility for the business outcome of the problems that code is supposed to solve — people who can speak both tech and biz — are exceptionally rare. They shouldn’t be; the language of business is mostly just elementary customer service, of the kind taught to entry level clerks at Nordstrom’s. But they are, so if you can do that, raise your rates.

To be a consultant, rather than an hourly-rate freelancer, you need two things:

  • insight
  • reputation

Bane’s rule, you don’t understand a distributed computing problem until you can get it to fit on a single machine first.

傅里叶变换

http://www.jezzamon.com/fourier/index.html

  1. 自身能力的复利
  2. 超级自信,自信到像疯子一样
  3. 学会独立思考
  4. 直接看这篇文章吧

go 规范

https://dave.cheney.net/practical-go/presentations/qcon-china.html

  1. Write shy code - modules that don’t reveal anything unnecessary to other modules and that don’t rely on other modules’ implementations.
  2. [A little] duplication is far cheaper than the wrong abstraction.
  3. Avoid package names like base, common, or util
  4. Keep package main small as small as possible
  5. Good code has lots of comments, bad code requires lots of comments.
  6. Don’t name your variables for their types ==> 这个自己倒是经常违反,后面注意一下

My #1 rule for existing codebases: Just because you wouldn’t have done it the way they did doesn’t mean they did it wrong. I think it’s developer nature to look at a huge pile of code that someone else wrote and immediately think: “This is a pile of crap. I can do better, so the first thing to do is rewrite all of this, my way (which just so happens to be The Right Way).”

Figure out what you’re trying to do, and what is keeping you from doing it. Take an iterative approach to get things done. Realize that after 3 years, they have hopefully fixed a lot of bugs and got to a solution that is somewhat mature and better than you can do in a week. 说的太对了。不要觉得别人写的代码就是一坨屎。你没有比别人强多少。自信不要用在这里。

https://wyag.thb.lt/ 从零开始自己写git

git 的core其实很简单

Productivity: every day do at least one measurable thing that puts forward your project, even if very small. <----非常重要

Expectations: don’t care about the outcome of your work, as long as you tried to put a lot of good efforts into it. Focus on trying to do the thing instead of focusing on the result it will have, or what people will think.

Stress: instead of being preoccupied about things, try to take care of them. During stressful situations, enjoy the small things of life, like eating or drinking a glass of wine, or playing with your daughter.

Socialization: let your inner person go out in every occasion in order to immediately push away people that don’t like you. Never try to fake being different (compared to what you are). This way you don’t have any filter, which is great, nor you have any doubt about people staying around having different expectations.

Life: it’s too short to hang out with people you don’t like or doing activities you don’t like. Focus on what you want.

ust by making stuff not ubiquitous, you add a little mental friction to using it that dissuades it usage. <–分心的东西做的难一点,所以手机上app尽量少一点

文档写作技巧: Functions should do one thing and one thing only. When you’re writing the function documentation and find that you added an “and”, it means the function is doing more than one thing. Break that function into two and remove the “and”.

(A dickish move you can do is to create the new functions, mark the current function as deprecated and add a sleep at the start of the function, in a way that people using the old function are forced to update.) 哈哈哈哈哈

For a long time, I kept a simple programming rule: The language I’m playing at home should not be the same language I’m using at work. This allowed me to learn new things that later I applied in the work codebase. 持续学习的节奏,因为语言不断变化,所以这个要求就保证了可以一直不断的学习新的语言

Keep a record of “stupid errors that took me more than 1 hour to solve” 被bug伤到的要好好记录,下一次的时间就缩短一些

docker打包的一些技巧

  1. Use more specific tags
  • So even in the least quantifiable situations, reflect back on what could’ve made a previous loss a future win.
  • Remember, there is no “magic moment” when you become great
  • great is just good, but repeatable.

微积分入门

common lisp的数据结构

think big, start small, act fast (quote from this: https://broadcast.listennotes.com/the-boring-technology-behind-listen-notes-56697c2e347b) Most of time, the biggest obstacle of building & shipping things is over thinking. What if this, what if that. Boy, you are not important at all. Everyone is busy in their own life. No one cares about you and the things you build, until you prove that you are worth other people’s attention. Even you screw up the initial product launch, few people will notice. Think big, start small, act fast. It’s absolutely okay to use the boring technology and start something simple (even ugly), as long as you actually solve problems.

http://gen.lib.rus.ec/search.php?&req=Mathematics&phrase=1&view=detailed&column=title&sort=def&sortmode=ASC&page=3 倒是一个找书的网站 https://mirtitles.org/2018/05/24/problems-in-elementary-mathematics-for-home-study-antonov-vygodsky-nikitin-sankin/

if your goal is to build a remarkable life, then busyness and exhaustion should be your enemy. If you’re chronically stressed and up late working, you’re doing something wrong. Just working hard is a recipe for failure for most people.

I don’t have a reference available but the concept of ‘Mission Command’ used by the UK Army amongst others contains the best and most succinct description I’ve seen of how to delegate a task to a subordinate. And is perfectly suited to many civilian situations as well. From memory, and paraphrasing, it boils down to State what you, as the leader, are trying to achieve, and why (‘the big picture’)

State what you want the subordinate to achieve

Define the resources available to the subordinate, and any constraints

Say how you want progress / issues to be reported

You don’t define how the subordinate should carry out the task – if they are competent and you trust them, they should be able to figure this out themselves.

[Edit] - the military distinction between command and control is also relevant to the civilian distinction between leadership and management. Paraphrasing slightly: Command is getting people to do something. Control is stopping them from doing something else.

Principles - Ray Dalio The Power of Now - Eckhart Tolle The Effective Executive - Peter F. Drucker Think and Grow Rich - Napoleon Hill Extreme Ownership - Jocko Willink, Leif Babin Influence - Robert B. Cialdini The Startup Way - Eric Ries The Lean Startup - Eric Ries 12 Rules for Life - Jordan B. Peterson Measure What Matters - John Doerr, Larry Page The Fish That Ate the Whale - Rich Cohen The E-Myth Revisited - Michael E. Gerber The Score Takes Care of Itself - Bill Walsh, Steve Jamison, Craig Walsh Management - Peter F. Drucker Thinking in Systems - Donella H. Meadows Blue Ocean Strategy - W. Chan Kim, Renee Mauborgne

c处理参数

http://www.usrsb.in/How-Old-School-C-Programmers-Process-Arguments.html

>It is about executing. It is about having the discipline to do the things you don’t want to do, but know they have to get done.

  • todo-year.txt : all goals for the year
  • todo-month.txt : track subset of annual goals to finish this month
  • todo-week.txt : track all monthly high-level tasks to finish this week
  • todo.txt : daily task plan based on weekly plan. Switch tasks every 1 hour. In a day, I plan for about 4 tasks, so each task ends up getting about 2 hours.