Front: Wo [[live]]lebst du?
Back: wohnst
There are a couple problems with this approach.
First, it’s a bit unnatural to type. Would you rather type “Wo wohnst du?”, or “Wo live du?”.
Second, it doesn’t work well if you want to generate text-to-speech (TTS) audio samples en masse with AwesomeTTS. If you pass this card to AwesomeTTS, it will generate audio with input “Wo [[ live ]]lebst du?”, which generates nonsense. What you want to feed it is: “Wo wohnst du?”
What if we use the built-in cloze template? Then the card would look like this:
Text: Wo {{c1::wohnst::live}}lebst du?
This is a bit more natural to type (start with “Wo wohnst du?” then add the cloze, then add the synonym). Anki has shortcuts for adding a cloze (⌘-C / ALT-C) and for adding superscript (⌘-SHIFT-= / ALT-SHIFT-=), making this a bit easier to type.
But this doesn’t solve the second problem. If we feed this to AwesomeTTS, it will generate audio for “Wo wohnstlebst du?” which is still nonsense.
My solution: Put synonyms in another field.
Text: Wo {{c1::wohnst::live}} du?
Synonyms: lebst
This is the easiest to work with, IMO. Once you add the cloze hint, you can hit TAB and then type out the synonyms. Also the Text field can be fed directly to AwesomeTTS and it will work as expected.
We can modify the template to show the synonyms following the cloze entry, so it looks exactly like it did before.
Here’s the front:
{{cloze:Text}}
<br/>
<br/>
<span id="synonyms"><sup>{{Synonyms}}</sup></span>
<script>
var synonyms = $("#synonyms")
synonyms.insertAfter($(".cloze"))
</script>
And the back is almost identical, just include the extra note:
{{cloze:Text}}
<br><br>
<span id="synonyms"><sup>{{Synonyms}}</sup></span>
<script>
var synonyms = $("#synonyms")
synonyms.insertAfter($(".cloze"))
</script>
<hr>
{{Back Extra}}
Voilà!
I’ve created a sample deck that contains the above template and note.
The original idea for this was provided by Vocabulary Labs course, which I highly recommend!
]]>“Man, your code reviews are brutal!” says John to your teammates. He’s talking about you.
“Why do you hate me so much?” writes Steve in an email to you.
Sound familiar? You might just be Seth, one of the people most familiar with the project and gatekeeper of the code base. You’re not out to write “brutal” reviews, or make your colleagues hate you. You just want to ensure that only the highest quality code makes it into production, as bug free as possible.
So why do your coworkers think you hate them? When you write things like:
can’t you just do it this other way?
kill this
you can’t do that
They really hear:
“only an idiot would do it this way”
“why would you commit this?”
“aren’t you smart enough to realise that that won’t work?”
But that’s not really how you intended to come off, or you likely wouldn’t be reading this.
To try to understand more of John and Steves’ perspectives, read Part 1 of this article.
So why should you even care? Can’t John and Steve just grow a thick skin? Why can’t they just stop whining?
Because they’re human, and we all have extremely varying experiences, all of which drive how we interpret the behaviour of others. Some people will assign a benevolent tone, while others will just as easily assign a malevolent one.
When John and Steve interpret your comments negatively, their performance will decline. They will feel like shit, their productivity will drop, and they will resent working with you. They will not be able to thrive in such an environment, and your overall team performance will suffer.
Fortunately, you can fix it. And when you do, your teammates will think more highly of you, enjoy working with you more, and be friendlier to you. Their morale will increase, and their productivity with it.
It all starts with having the right tone. Without proper use of tone, it’s very easy to to lose the meaning behind the message.
When tone isn’t explicit, it’s easy to interpret it negatively. It’s also highly individual: John may read a comment as a friendly suggestion, while Steve reads it as an attack on his intelligence.
Writing comments without paying attention to tone is a default mode for most people. You must consciously insert tone when writing in order to prevent John and Steve from attributing a negative tone.
Fortunately, it’s a lot easier to fix than you would think. With some practice it will become more natural, and eventually you will be inserting explicit tone automatically.
The following techniques aren’t just applicable to just code reviews, but to all text-based communication you’ll use in daily life: emails, texting, chat, etc. Follow these suggestions and John and Steve will no longer think of you as a brutal gatekeeper:
You can use the passive voice to remove a subject from the sentence, placing emphasis on the outcome of the action. This focuses on the problem, and not the person. Instead of “You must use four spaces for indentation”, use “Four spaces must be used for indentation.” Notice how the “you” has been completely removed from the sentence.
Example
You can also use the collective “we” in place of “you”. For example, instead of “You must always re-throw exceptions here”, use “We must always re-throw exceptions here.” This de-emphasizes the original submitter as the target of the comment, and re-emphasizes that this is a team effort.
Example
Use the passive voice, the collective “we”, and focus on the problem, not the person.
Asking questions is also a great way to bring up an issue. They become responsible for the answer, and this gives them a chance to explain themselves. For example: Instead of “this will fail”, try “What happens if the gidget is set to 42?” It could be that they have a legitimate reason for submitting the code as it is.
Example
Additionally, build rapport with the submitter. Eat lunch with them, play games with them (in person or online), get to know them. If this is something that is difficult for you, begin with a casual “got any plans for the weekend?” Show some interest in their response. If they answer with “I did some karate”, ask them about it. “Oh cool! How long have you been doing karate for? What do you enjoy about it?” Keep the questions focused on them, and don’t bring the conversation back to you. Bad example: “Oh cool! I’ve always wanted to do karate.” This brings the conversation back to you, and gives them the opportunity to lose interest.
Avoid imperative forms. Make suggestions, not commands. Instead of “do it this way”, try “it might work better if we did it this way.” If you issue commands you will come across as demanding.
Prefer an informal tone over a formal tone. Instead of “This could be null here.”, try “this could be null here”, noting the lack of punctuation. Punctuation is still important, but the use of initial capitals and final periods can be safely discarded.
Don’t end your statements with a period. Studies have shown that ending your sentences with a period makes them come across as less sincere.
Use liberal use of emoticons and emoji. They explicitly demonstrate tone :) If you’re worried that the receiver will be annoyed by them, pay attention to how they themselves write, and tailor your level of emoticons to match theirs.
Don’t be terse. Terseness comes across as impatient and frustrated. Instead of “don’t do this”, prefer “if we do it this way, these bad things could happen”, or even better: “can you foresee any bad things happening if we do it this way?”
Admit that you may not understand everything. Instead of “don’t do this”, try “I don’t understand this. Would you be able to elaborate?”
Have clear guidelines and coding styles so that they don’t turn into an issue during reviews. Have an automated tool to check those styles before code is even committed.
Make it explicit when a comment is a suggestion: “it might work better if this implementation had rockets”.
Make it explicit when a comment is a mandatory change: “unfortunately we must transmit the the signal here, or the aliens will die”
Add compliments, acknowledgement, and gratitude: “Thanks, this looks awesome! Just a few things that I think we should change.”
Don’t write in anger. If you find yourself thinking “how the fuck did this get written?” Take a deep breath, step away from the computer for a few minutes. Calm down, come back, and write “I’m not sure this will run without throwing an error.” Otherwise you risk building resentment in the receiver.
Still worried that your colleagues might be interpreting your comments negatively? Grab them and go over your code review together, whether it’s in person or using Screenhero. Then you can explicitly add your tone in your voice.
With these guidelines, you’ll start to find that John and Steve are friendlier towards you, and their productivity will increase. These techniques will help you across all written communication, not just for code reviews. You will become a more pleasant person to work with, and that alone makes it worth the effort.
]]>“Jerk”, “Asshole”, “Ugh, what now?”, “Do it yourself!”, “Why are you so damned picky?”
Sound like things you’ve thought to yourself when Seth submits his review for your most recent pull request? Seth is the rockstar, know-it-all, pretentious, two-spaces-not-four and definitely-no-tabs-ever guy. He’s the gate-keeper of all code. He reviews all pull requests, and nothing gets into the code base without his approval. It’s his fault that you can’t meet your deadlines. Why can’t he just approve it so that you can move on to the next task?
Well, he could. But there are some very good reasons he wouldn’t want to.
It turns out that Seth probably isn’t as bad of a guy as you would think. The reason you feel this way could be aggravated by the tone, or more importantly, the lack of tone that was used in his comments while reviewing your code. That his comments made you feel shitty are a combination of multiple factors:
All of these factors can combine to ruin the relationship you have with Seth. They can also turn your this-should-be-awesome day, into fuck-this-get-me-out-of-here day, where you struggle to crawl out of bed the next day, just to plop yourself in front of the computer, only to re-read the comments and spiral back into that foul and depressive mood again.
But there is a way out: Seth isn’t actually an asshole — it just seems that way due to how you’re interpreting his comments. Seth really just wants to make sure that the code that makes it into production doesn’t introduce any bugs.
Are you Seth? Then I recommend you read Part 2. For now, we’ll talk about how it is to be the receiver of Seth’s comments.
Tuesday morning. Opening Gmail, you see a thread containing comments from the pull request you submitted yesterday. It’s from Seth, of course. You grit your teeth, wondering if you should put your mouthguard back in. At this rate, your molars will be ground down by the time you hit forty. Tensing your muscles, you open the thread.
kill this
this must be a typo.
this does not look good to me. Why was this done?
Yup, sounds like Seth is his normal, moody self. But wait, there’s more:
can you not just change it so that it uses attributes?
why can’t you just do it this way?
can you explain this change?
And you’ve got your daily standup in ten minutes! Now you’re thinking that it might just be best to call in sick and play video games all day.
Does this sound like you? Even just a little bit? Read on. Even if it doesn’t sound like you, you may run into this in the future, so you may want to keep these things in mind.
It’s very easy to see Seth blaming you for this. “Can you not just do this?” “You must surround function parenthesis with spaces”. It’s all your fault, and Seth is making sure that you remember that.
Well, not really. There could be an entirely different side of this story: Seth is in a rush, and only has a few minutes to conduct your code review, one of many that he has to get done every day. It shouldn’t come as a surprise that his comments are terse, such as “remove this”. Seth doesn’t really hate you at all, he just wants to get the code review over with so he can go on to fix the issue that brought the database down last week.
How did this conspire to ruin your day in the first place?
Well, Seth’s comments lack tone. When they lack tone, it’s very easy to insert a tone that matches your current mood, or one that reflects how you think Seth feels about you. If you think Seth hates you, you will interpret it in that tone. If you’re feeling down or frustrated, Seth’s comments will seem like he is frustrated too. And after you hear those tones once, you’ll likely interpret his future comments in similar tones.
“That’s great, but what can I do about it?” you ask.
Well, it turns out that you can change how you interpret such messages. In Learned Optimism, Martin Seligman writes about a technique that people can use to help stop interpreting comments as personal, general, and permanent, and interpreting them as impersonal, specific, and temporary. Reginald Braithwaite gives a much better overview here. Go read it.
You can learn to read such comments in a more positive, friendly tone, but it also helps to build a good rapport with your reviewers. If you haven’t met them in person yet, make it a priority to to do, if possible. Once you get to know someone in person, it becomes a lot easier for you to transfer their in-person personality to their tone-less comments.
If it’s not feasible to meet them in person, try to organise things you can do together online. Play some games online together, with microphones on, or have a “happy hour” for the team, where everyone jumps on hangouts and has a virtual drink together.
Also if you’re comfortable with it, the best course of action may be to try to talk to Seth directly. Don’t open with a bold statement like “Why do you hate me?” That implies that Seth actually does hate you, when it’s likely far from the truth. Try something like this: “When you do X, I feel Y, and that makes me Z”. Following that formula focuses on your feelings and the impact it’s having on you, rather than attacking Seth. Try it out: “When you say ‘kill this’, that makes me feel like you’re frustrated with me, and that makes it more difficult for me to come into the office.”
If that sounds really daunting to you, or you don’t feel comfortable enough with Seth to talk to him like that, you may try an indirect approach. Post the second part of this article in your team’s chat, suggesting that everyone read it. When Seth comments on another team member’s pull request, point out to him how negatively his comment can be read, and encourage him to add explicit tone to his posts.
The key take away here is that you don’t want to attack Seth; That will only make things worse. Focus on how it feels to be on the receiving end of those comments, and Seth will be able to show a bit more empathy. Encourage, don’t disparage.
You may also feel shame that Seth is pointing out something that you know you could have done better, but you have to take it into context: You may not consider it to be your best work, but it was the best effort you could give at that time. If you’re under pressure, in a time crunch, working overtime, distracted, sick, or otherwise exhausted, you’re not going to be able to do your best work. In this situation, it’s best to view it as a chance to improve something that you did before, and to know that the next time you do something like that, it will be caught by Seth. It’s also a chance for you to be grateful that such code did not make it into production.
How can you continue to work with Seth? In summary, here is how you can make it more enjoyable:
As a reviewer, Seth has a hand in it as well. He can spend just a little bit of effort to add some tone to his comments. In part two, learn how to not be a jerk when doing a code review.
]]>Communication: A leader should foster communication amongst the team, as well as between other teams. It’s better to over-communicate rather than under-communicate. Communication should ideally be clear and direct.
Patience: Impatience adds stress and anxiety to team members, who otherwise do their best work when relaxed and comfortable. Team members should feel confident in admitting mistakes (after all, everyone makes them), and should not be punished for them.
Listening: One of the most important skills, in my opinion. A team member should feel comfortable bringing any problem to a leader. If one does not listen, that level of comfort is difficult to establish. A leader should not interrupt others when they speak, and should seek to understand what the team member is trying to communicate, rather than waiting for their turn to speak.
Humility: I believe everyone can learn something from anyone else, regardless of their age, experience, or background. Keep an open mind, and be open to new surprises. Leaders are not better than others.
Appreciation: A leader should show appreciation to all around them, but especially their team members. A lack of appreciation makes others feel unimportant, decreasing their morale and motivation.
Encouragement: One should encourage, not disparage. Reward the good behaviour that they observe by showing appreciation. Encouragement helps team members go further, and increases motivation.
Vision: She should know where the team wants to go, and be able to help the team get there (even if they themselves don’t know how). This includes both short term and long term goals. They should also show how each team member’s work contributes to the team’s goals.
Focus: A leader should help the team focus their efforts, steering them in the right direction so that they can strive towards their vision. They should set goals and help the team focus on achieving them.
Mentorship: They should help those around him grow, challenging them to expand and strengthen their skills, both professionally and personally. Identify weaknesses and encourage team members to address them.
Interest: Take a genuine interest in team members, building rapport with them and supporting them. There should also be a genuine interest in the problem domain, and a leader should seek to grow their expertise with it.
Problem Solving: A leader should be able to help solve the team’s problems, whether those problems are within the team (ie. conflicts) or without (ie. technological or organizational blockers). Solving these problems lets the team focus on achieving their vision, without being distracted by other issues. A leader can help identify these problems, and also propose solutions and drive their resolution. These problems can be anything: technical, organizational, environmental, and personal.
Collaboration: Getting the team working together is more effective than issuing orders to team members. People feel powerless when commanded to do something. Collaboration gives the power to the team, regardless of seniority or title. A leader should do what they can to encourage such an atmosphere. When a problem arises, the focus to solve it is on the problem itself, not to lay blame on those involved.
Tolerance: A leader should foster an environment of tolerance, allowing team members to be themselves in an environment free of prejudice and oppression. This means immediately tackling issues such as (but not limited to) sexism, homophobia, racism, bullying, or antagonism.
Feedback: A leader is able to give feedback in a constructive and useful way, helping team members grow, rather than criticizing them and making them feel resentful.
See also my principles for software development.
Last updated 2021-02-09
]]>Hello! I want to ask you to share your experience or ideas about what is the better way to improve the English level. Of course, the question is not simple how it seems because I have not bad level (according to a test it closer to advance) and I try to use all general advice like use English sources for getting information (for my work and other aspects of my life), watch videos in English etc., but I still feel not comfortable in a speaking part and sometimes with understanding (some accents are easy to understand some harder). How did you manage similar problems? Thanks!
I believe the best way to improve your speaking is to, well, speak. The more you can speak, the faster you will improve. It can help to figure out what specific problems are being encountered. Others having problems understanding what you’re saying? Improve your pronunciation. Can’t recall the word you want to use in the middle of a sentence? Use Spaced Repetition Software (SRS) to boost your recall rates. Don’t know the word to use in the sentence? Increase your vocabulary size.
To speak more, try to incorporate speaking into your life more. If you can speak your target language with your friends or family, try to do so as much as you can. If you’re watching TV, you can repeat after hearing something (“shadowing”). You can also talk to yourself, which is maybe strange, but can be very effective. There’s an article over at Universe of Memory that goes into the details of talking to oneself. But speaking without feedback risks ingraining mistakes. To that end, I recommend hiring a native speaker who can give you feedback. They don’t need to be a trained teacher (those can be very expensive) - just a native speaker who can tell you when you’re saying something wrong.
I’ve had very good luck finding native speakers on Italki - you can find a native speaker there under “community tutors”. You can also find a language exchange partner, but I don’t recommend them. If you’re doing an exchange, you’re spending time and effort on your own language, when you could be spending that time and effort learning your target language. It’s also a significant amount of effort to find a suitable partner in the first place. Go with a community tutor if you have the financial means.
To improve your pronunciation, I recommend learning the IPA of your target language. Once you identify the words that you have trouble pronouncing, you can use the IPA to identify the specific sounds that are difficult for you, then intentionally practice them. Note that unless you’ve intentionally trained your ear to hear these new sounds, it’s unlikely that you’re hearing (and thus pronouncing) them correctly. As an example, see Perception of English /r/ and /l/ by Japanese speakers. The Speechling app can also help with this. You record yourself speaking sentences aloud, which are then reviewed by a native speaker who points out what is being said incorrectly.
To increase your vocabulary size, I recommend actively engaging with new words, or with words that you find yourself forgetting. To active engage, you can create sentences (written, typed or spoken) using these words. You can type them into your SRS application to decrease the chance that you will forget them.
To get used to different accents and speakers, listen to media from many different sources. YouTube is a fantastic resource for this. Listen actively, and try to pick out words. Take note of new words you don’t know and try to use them. I also recommend the article Listening comprehension in a foreign language - 12 ways to improve it.
To improve the recall of your vocabulary, I recommend using Spaced Repetition Software, in particular Anki. The vocabulary you learn will be periodically shown to you based on how well you know it. This helps slow down memory decay (see Ebbinghaus’s Forgetting Curve and the Spacing Effect). It can also be useful in identifying vocabulary that you need to pay more attention to, for example a word that you keep getting incorrect can be used in more sentences, help to boost the recall rate.
Disclaimer: I am no expert on language learning. I have some background knowledge, have read a bunch about it, but they were mostly secondary sources. I have tried many things and have failed more times than I have succeeded. Take my advice with a grain of salt. I highly recommend Universe of Memory as Bartosz actually cites his sources, so you can question his recommendations by delving into the source material.
]]>Don’t leave work unfinished - Work that is started but not finished is a liability. At best, it means a feature isn’t in production sooner than it could be (representing wasted opportunity). At worst, the feature will suffer from software rot, and may require substantial rewriting if left long enough.
Work on only one thing at a time - Mental context switching is expensive. Focus as much as possible until that item is done.
Teamwork - The team as a whole is more important than the individual. This means that you should write maintainable code, ask for help when you get stuck, and help out your colleagues when they need it.
Review pull requests thoroughly and in a timely manner - as part of teamwork and leaving work unfinished, review your colleagues’ work quickly. If they write a PR and it sits for a week, that is means it takes one week longer for that feature to make it into production.
Fix bugs first - Bugs should be fixed before anything else. They are easier to fix when fresh, and existing bugs represent potential bad experience for enduser. See the Pragmatic Programmers’ broken window theory.
Be aware of errors - Whenever an error or problem occurs, we must be notified of it. Otherwise, only users will experience it, and not all users report errors. Also if a bug is fixed before a user first notices, the bug doesn’t exist from their perspective. An app slowing down to unusable speeds is considered a bug.
Don’t live with pain - When something is frustrating, take the time to fix the problem for everyone. Automate common tasks. This makes life easier, and makes the software easier to work with. It’s not always possible given time contraints, but it’s worth it. This is how big things such as Rails or Meteor get built.
Produce high quality code - Take the time to do things correctly. Quality is worth it.
Be pragmatic (but balance ideals) - Striving for ideals is fantastic, but shipping usable code is the most important.
Don’t let email/requests go unanswered - Others have taken the time to ask something of you. Be courteous, and don’t make them wait.
Provide test coverage - Do this where possible. The value it provides is tremendous. Try to consider a feature to be complete when it has test coverage.
Keep learning - Always be trying to learn new things. This includes new ways to use existing tools, or new tools altogether. Tools range from programming languages, frameworks, paradigms, editors, to soft skills such as empathy and listening skills.
Blame problems not people - Don’t forget that code is written by humans, with real feelings. Focus on the problem itself; blaming the author is counterproductive.
Encourage, don’t discourage - Help others improve their code. Don’t put them down because they wrote code that you (subjectively) could be better. Yours could also always be better.
Be humble - Realise that you can learn from everyone out there, including those are just learning to write code, and even from those who don’t write code at all.
A good chunk of these have been taken from OK GROW!’s development process guide, which I’ve contributed to a bit.
A lot of these may seem like common sense, and I hope that they do. That’s a sign that you’ve got solid guidelines in place. But I’ve had some encounters with people who haven’t given such things any consideration, just like there are companies out there that still don’t use source code control.
What sort of guidelines do you use in your development process? Email me at rgould@u2622.ca or leave a comment below. I’d love to hear them!
]]>I recommend starting by watching a series of Douglas Crockford’s lectures on JavaScript, and then following it with Reginald Braithwaite’s Javascript Allongé.
I recommend doing the above in that order. Allongé is more advanced and builds off of topics covered by Crockford. Each step will help bring your JavaScript game to the next level, with Crockford’s lessons establishing solid fundamentals, and Allongé teaching (in a very effective manner) the more advanced usages of functional programming with JS.
Note that I did all of the above (and worked through the exercises in Allongé) before I even touched Meteor, and for the most part, the only Meteor help I’ve needed has been the official Meteor docs. Having such a solid foundation of knowledge let me pick up Meteor with lightning speed, and all of those skills will stay with me when it comes time to learn another framework.
If you have trouble following Crockford’s lectures, then I recommend reading his print edition of JavaScript: The Good Parts instead. While you’re reading it, really work through the examples to make sure you’re understanding it as you go along.
Have you ever felt that your JavaScript skills were inadequate? Have you ever looked inside one of the libraries you use (jQuery perhaps?) and felt as though you didn’t understand JavaScript at all? I want to hear about it. Email me with your story (write as much or as little as you’d like).
Immature Environment: The biggest problem right now is that Meteor is new. Pretty much brand new, in the scope of web development. It’s not even version 1.0 yet, though it’s getting close. This means that it doesn’t have as many users, as many tutorials, as many books, as many screencasts. It can be hard if you run into a problem that no one else has run into yet, so you’ll need to be willing to dig into it a bit yourself. I’ve been there, and fortunately Meteor’s codebase is fairly cleanly written (especially compared to Rails and AngularJS, two other frameworks whose code I’ve read).
Not Widely Supported: Another consequence of being so new is that there aren’t as many hosting services available for Meteor apps yet. It is possible to deploy Meteor on Heroku, and in my experience it works well, though it feels very raw.
Nothing but JavaScript: You must run JavaScript (or Coffeescript) on the server side. This isn’t a big deal for me, but JS is definitely far from the first language I would choose to work with. The upside is that you can run the same code on the server and the browser, without worrying about having to cross-compile from another language.
Only MongoDB: As of now, the only supported database is MongoDB. They have plans to expand this in the future.
Rapidly Changing: The Meteor API is rapidly changing, so each new minor version may bring breaking changes. This is expected to lessen as it reaches 1.0.
Testing Frameworks: Testing frameworks haven’t been a high priority since the beginning, and the ones available so far have tended to be cumbersome and brittle. The community is working on solutions, but nothing stable has yet emerged, and the testing culture is nothing like the Ruby on Rails community’s.
While there are many disadvantages, I feel like the advantages heavily outweigh them (usually). But the list of advantages is for another post entirely!
What are some other disadvantages you can think of? Email me or leave a comment!
Declare a server-side route in your Routes.map declaration:
Router.map(function() {
... // Your other routes go here
this.route('hook', {
path: '/hook',
where: 'server',
action: function() {
// Watch the Meteor log to see this output
console.log("Hook called.");
console.log("Headers: ", this.request.headers);
console.log("Data: ", this.request.body);
this.response.writeHead(200, {'Content-Type': 'text/html'});
this.response.write("You wrote: " + this.request.body.message);
this.response.write("\n");
// `this.response.end` *must* be called, or else the connection is left open.
this.response.end('Success!\n');
}
});
});
To test it out, issue this curl command from the command line:
curl -H "Content-Type: application/json" -d '{"message":"foo"}' http://localhost:3000/hook
The documentation for this.response
and this.request
are available on the node.js website: http://nodejs.org/api/http.html
I’ve created a sample Meteor application demonstrating this, which you can view at https://github.com/rgould/meteor-posthooks
Not clear enough? Send me an email at rgould@u2622.ca for some more help!
Mammút - They play energetic rock music, bordering on post-punk sometimes. The first Icelandic language band I liked, and my favourite still. Here’s Svefnsýkt: <iframe width="420" height="315" src="http://www.youtube.com/embed/aeGZriDklEo" frameborder="0" allowfullscreen></iframe> Bónus: Rauðilækur
Q4U - Postpunk from the 80s, mostly in Icelandic. They’re still around. Here’s Sigurinn: <iframe width="420" height="315" src="http://www.youtube.com/embed/iiWcZKhWlQA" frameborder="0" allowfullscreen></iframe> Bónus: Snjóhvít
Samaris - Atmospheric minimal electro/triphop with clarinet. Very haunting. Here’s Góða Tungl: <iframe width="560" height="315" src="http://www.youtube.com/embed/_pKuzdMFE8k" frameborder="0" allowfullscreen></iframe> Bónus: Stofnar Falla
Nóra: Indie rock, ranging from upbeat and energetic to atmospheric and introspective. The more I listen, the more I like it. They sing entirely in Icelandic. Here’s Himinbrim: <iframe width="420" height="315" src="http://www.youtube.com/embed/w66kIAWBFs8" frameborder="0" allowfullscreen></iframe> Bónus: Sjónskekkja
Lockerbie - Post-rock, but with a bit more pop/rock than usually characterised by Icelandic post-rock. Here’s Snjóljón: <iframe width="420" height="315" src="http://www.youtube.com/embed/cUWzNsPHcEQ" frameborder="0" allowfullscreen></iframe>
Úlfur Úlfur - Hiphop with awesome backing percussion. They sing entirely in Icelandic. Here’s Út: <iframe width="560" height="315" src="http://www.youtube.com/embed/jCgbt73gD74" frameborder="0" allowfullscreen></iframe> Bónus: Ég er farinn
Pascal Pinon - D.I.Y., lo-fi, indie pop electronic. Many songs in Icelandic. Here’s Ekki Vanmeta: <iframe width="100%" height="166" scrolling="no" frameborder="no" src="https://w.soundcloud.com/player/?url=http%3A%2F%2Fapi.soundcloud.com%2Ftracks%2F71960187"></iframe> Bónus: Sandur
Sólstafir - Post-black metal, with elements of country and rock. They are amazing live. Their album Svartir Sandar is entirely in Icelandic and highly recommended. Here’s Fjara: <iframe width="420" height="315" src="http://www.youtube.com/embed/A6j7mUxGz20" frameborder="0" allowfullscreen></iframe> Bónus: Svartir Sandar
There’s lots of music that I’ve discovered that I didn’t cover here, but I only wanted to showcase the music I liked the most. Feel free to leave other suggestions in the comments.
]]>Download: mov 24MB, 8:26 (Recommended)
Watch (recommended in full screen and in HD):
Notes:
Make an alias:
alias l="ls -al"
alias glog="git log"
Add those to your ~/.aliasrc
.
Modify ~/.zshrc
or ~/.bashrc
(works for both):
if [[ -r ~/.aliasrc ]]; then
source ~/.aliasrc
fi
View shell history: history
View count of common commands:
history | awk '{ print $2 }' | sort | uniq -c | sort -n
history | awk '{ print $2,$3 }' | sort | uniq -c | sort -n
Use that output to create better aliases!
Here’s some of my favourite aliases:
alias ..='cd ..'
alias ...='cd ../..'
alias ....='cd ../../../'
alias .....='cd ../../../../'
alias be='bundle exec'
alias g=git
alias ga='git add'
alias gc='git commit -v'
alias gca='git commit -v -a'
alias gch='git checkout'
alias gl='git pull'
alias gst='git status'
alias l='ls -al'
]]>The problem turned out to be that the code was using validates_presence_of :hometown_id
, where hometown
is the name of the association, and the solution is to use validates_presence_of :hometown
, or the newer version: validates :hometown, presence: true
.
If you have a given class:
class Viking < ActiveRecord::Base
belongs_to :hometown
validates_presence_of :hometown_id
end
and blueprints:
Viking.blueprint do
name { "Heiðrek" }
hometown
end
Then calling Viking.make
will properly return an unsaved Viking object (with a Hometown object viking.hometown
), but valid?
will return false.
Calling Viking.make!
will throw an exception: ActiveRecord::RecordInvalid: Validation failed: Hometown can't be blank
If you really want to keep using validates_presence_of :hometown_id
, you can modify the blueprint like this:
Viking.blueprint do
name { "Heiðrek" }
hometown { Hometown.make! }
end
Then Viking.make! will succeed. Viking.make will also work, and will return an unsaved Viking object, but it will actually create and save the associated Hometown object, which negates part of the point of calling .make
instead of .make!
(make
creates objects but does not save them to the database, giving quite a performance boost for test suites).
The proper solution is to adjust the validation in your model:
class Viking < ActiveRecord::Base
belongs_to :hometown
validates :hometown, presence: true
validates_associated :hometown
end
The key is that we’ve changed validates_presence_of :hometown_id
to validates :hometown, presence: true
. The validation actually checks the association itself, not the presence of an id field (which is only ever set once the hometown is saved).
We’ve also added a validates_associated :hometown
call, which will check hometown.valid?
before saving, and if the hometown fails validation, then the viking object will as well.
See API docs about validations here:
]]>I just set up this new octopress instance in roughly half an hour! Hooray!
]]>