Posts Tagged “development”
Mar 9, 2021
The last months I have been working on my first video game. First I made a 2D prototype (because everyone said that it was a bad idea to make your first video game 3D), and then I worked on the 3D version, which was what I wanted to make in the first place.
The 3D version involved a lot of Blender (in fact, I would imagine that more than half the time spent on it was really inside of Blender, not writing code), so I figured I would make a cheatsheet for myself, which others would maybe find useful.
This is probably not going to make any sense if you have never used Blender: it’s not a tutorial and it won’t teach you how to use it. However, if you start using Blender and have a need to remember keyboard shortcuts or want to discover some things Blender can do for you that you might not know yet, this might be useful!
One of the most important things is that 1, 2, and 3 choose between vertex, edge, and face selection. You have to make sure you’re in the right mode before anything else.
- Ctrl-click will select from the last selected item (vertex/edge/face) to the clicked item (Blender finds the shortest way, sort of).
- Alt-click on an item to select all “related” items (depends on context and might not always do what you want, but it can be used to select a whole line). This is usually a horizontal or vertical “line” containing the clicked item.
- Shit-click to add the clicked item to the current selection.
- C to “circle select”. This is a special mode that will let you modify the current selection by adding new items (hold the left mouse button and drag the circle), or removing items (hold the middle click and drag the circle). You can make the circle bigger or smaller with the mouse wheel, and you exit the circle select mode by right clicking.
- Shift-Z toggles “see-through” mode, useful to select things that are on the back.
- Ctrl-NumPad+ expand selection by taking items that surround the current selection.
- J after selecting two vertices will create an edge between them.
- F3 -> Subdivide to subdivide a face (eg. single-face plane into plane with many faces that can be sculpted).
- E to extrude.
- S to scale.
- I to inset.
- M to get the menu after selecting vertices, then choose “By Distance” to collapse vertices that are in the same place. Eliminating this kind of duplicate vertices is really useful to avoid problems with your geometry.
- Shift-Tab to toggle snapping (can choose in the menu if snap to vertices, by distance, or other things).
- O for proportional editing (whatever operation you perform will not only affect the current selection, but also the surrounding items). You can change the area of effect with the mouse wheel. There are several modes for proportional editing, including “random”. See the menu at the top.
- X, Y, or Z when moving/scaling to lock the move/scale to that axis.
- Shift-X, Shift-Y, or Shift-Z when moving/scaling to lock the move/scale to exclude that axis.
- Ctrl-drag while moving a vertex along a given axis to snap the other axes to the vertex under the cursor (useful to align stuff).
- Ctrl-R to chop a face (and all connected “in the same direction”) in many.
- Shift-D to duplicate an object.
- Alt-D to duplicate an object but keeping it linked to the original. This can potentially save a ton of space and processing if you are going to have many identical copies of the same object. It also means that they will stay the same, so if you edit one, you will be editing all linked-duplicated objects at once.
- F creates a faces from the selected vertices.
- LoopTools extension is great! You have to add it in Preferences. It adds a submenu at the top of the menu in edit mode.
Blender is a wonderful, free tool for 3D modelling that has all sorts of features (and not only for 3D modelling!). If you want to learn 3D low poly modelling, I recommend you start with Learn Low Poly Modeling in Blender 2.83.
Oct 24, 2011
About the technology, I used the Markdown format for the pages thanks to the markdown-js library (it’s really nice that the module has an intermediate tree format that you can parse to add your own stuff before converting to HTML, like e.g. wikipage links!), express for the whole application structure and js-test-driver + jsautotest + a bit of syntax sugar from Sinon.js for the tests (but looking forward to trying out Buster.js when it’s released!). The deployment to Joyent’s Node.js SmartMachine was reasonably easy. Actually, it was pretty easy once I figured the following:
You must not forget to listen in the correct port, with
server.listen(process.env.PORT || 8001)
There are a couple of pretty useful Node.js-related command-line utilities to check logs, restart applications and so on
The configuration of the application can be done via
npm config, see npm integration on Joyent’s Wiki
If you’re curious to see the code, play with it or use it yourself, take a peek to the Wiki-Toki repository on GitHub. Happy hacking!
Oct 13, 2011
This is the third and last part of my summary of Pragmatic Thinking & Learning, by Andy Hunt. See parts one and two on this same blog. This part will cover chapters “Gain experience”, “Manage Focus” and “Beyond Expertise”.
Your brain is made to learn by exploring and building mental models on your own, not by receiving information passively (see amazing footage of tennis teacher in Alan Kay’s Doing with Images Makes Symbols, starting on 55:30). In real life there’s no curriculum, you’ll make mistakes and it will get messy: the kind of feedback you need. We learn by “playing”, but that doesn’t mean easy or non-business-like. Papert students called it “fun” because it was hard, not in spite of.
Leveraging existing knowledge helps learning new skills: we can often find similarities, literal or metaphorical, with existing skills. However, careful not to stick with the similarity. Fully embrace the new skill’s unique characteristics.
Failures are valuable because they can lead to study and understand what went wrong and how to fix it. They are critical to success, but only when well-managed. A good environment for good failures needs freedom to experiment (few problems have a single solution; prototype more than one solution to a problem), ability to backtrack to a stable state, reproduce any work product as of any time (source control, and the ability to run those versions of the program), ability to demonstrate progress (get comparable feedback between versions). Version control, unit testing and automation give this environment. A supporting environment can make or break learning for anyone.
Tip: to raise awareness when some code fails without apparent reason, try to imagine what the code should look like, then compare it to the real thing.
Time pressure actively shuts things down. Your vision narrows, and R-mode doesn’t get the chance to work at all.
When not doing anything, the L-mode will produce incessant mental chatter, which interferes with R-mode processing. Meditation helps controlling the L-mode “monkey voice”.
When meditating you don’t want trance, falling asleep, or “contemplate the big mystery”, but to sink into a relaxed awareness of yourself and your environment without judgement or making responses. Meditation exercise suggestion: find a quiet spot; sit in a comfortable, alert position with a straight back (become aware of any tension and fix it); close you eyes and focus your awareness on your breath; be aware of the rhythm (don’t try to change it, just be aware); keep your mind focused on your breath (do not use words or start a conversation with yourself); when you start thinking about some topic or having a conversation with yourself, let the thoughts go and get the focus back on the breath. Even if you mind is wandering often, the exercise of bringing yourself back is useful.
You have to let your thoughts “marinate” to get the best results. Different people have different methods to marinate (sitting around doing nothing, humming, eating a crunchy snack, making paper dolls…). Thinking about at least three solutions to a problem gives you the confidence that you have thought “enough” about it. Then, you can let those ideas marinate and come up with the best solution.
Develop your exocortex (mental memory or processing outside your physical brain: book collection, notes, favourite IDE, etc).
Deliberate switching to e-mail/IM. Close what you’re working on, take a deep breath, then switch.
Have a way to note things quickly when they come up, without losing the flow or what you were doing (wiki/scratchpad inside you IDE or whatever).
When stuck or bored, doodle on a piece of paper, or go for a walk (without talking to anyone). That helps against checking the internet or e-mail.
Don’t answer IM right away, put up a sign (“don’t disturb”) during a debugging session or similar, or close the door if you have one. When you do get interrupted, try to save your mental state before you lose it.
Get two monitors (same size and brand) to keep the whole context at sight. Organise virtual desktops by task (communications/distractions, writing, coding/checking documentation, surfing), not by kind of application (browsers, editors, terminals).
In summary: learn to quiet your chattering L-mode, deliberately work with and add to thoughts in progress, and be aware of how expensive context switching can be.
Change is harder than it looks, old habits don’t go away easily. Don’t be hard on yourself, just correct it and go back to the right path. Suggestions to make effective change:
Start with a plan. Keep track of what you have accomplished, it’s probably more than you think.
Inaction is the enemy, not error. The danger is not doing things wrong, is not doing anything.
New habits take time. Expect at least three weeks, maybe more.
Belief is real. If you think you’ll fail, you will.
Take small, next steps. Keep your big goal in mind, but don’t try to spell out all steps you need to get there.
Possible first steps (complete list on p. 247-248, this is just two highlights): (1) pick two things that’ll help you maintain context and avoid interruption, do them right away; (2) open your mind to aesthetics and additional sensory information (your cubicle, desktop, code: how “pleasing” is it?).
You don’t want to become a “niche expert”: approach learning without preconceived notions, prior judgement or a fixed viewpoint; be aware of your own reaction to new technology and ideas; be aware of yourself and the context. The biggest reason any of us fail is the autopilot.
And this is the end. I hope you liked it.
Oct 12, 2011
This is the second part of my summary of Andy Hunt’s “Pragmatic Thinking & Learning”. See the first part on this blog. This part will cover chapters ”Get in Your Right Mind”, “Debug Your Mind” and ‘‘Learn Deliberately”.
Get in Your Right Mind
A good way to involve your brain more is to use more senses than usual. For tactile you can use building blocks like Lego, CRC cards, etc. Example of “role-playing” a software design on p. 77. The advantage of using the R-mode is not that it’s a panacea, it’s simply to use the other half of your brain too (reference to pair programming). Story of the climbing teacher on p. 81: the importance of feeling something first (R-mode) before learning it’s theory (L-mode), because it gives you the context to understand the theory and explanations better. Learning can be impeded by trying to memorise facts when you don’t grasp the whole yet. When creating, be comfortable with the absurd and impractical; when learning, get “used to it” before learning and memorising. Using metaphors can open up creativity because they communicate the R-mode and the L-mode (wordnet can help when creating metaphors).
Tip: the “morning pages” technique (p. 98). Write them first thing in the morning (before coffee, shower or anything else); write at least three pages by hand, without computer; do not censor what you write; do not skip a day. Blogging is also a good exercise (what you think about a topic, what you can defend publicly).
Tip: learn martial arts or yoga to improve concentration (p. 103). Tip: break small, daily routines (turn off the autopilot).
Forcing the brain to reconcile unlike patterns broadens the scope of material under consideration (see Zen koans and Greek oracles on p. 107). Reference to oblique strategies (has electronic versions, including an Android version!).
Debug Your Mind
We make decisions and solve problems based on faulty memory and our emotional state of the time, ignoring crucial facts, etc. Some cognitive biases: anchoring (ref: experiment with numbers and prices in predictably irrational), fundamental attribution error (other people behave based on their personality, we have excuses for our own behaviour; in reality, behaviour is often caused by the context), self-serving bias (“it’s my success”, but “it’s not my failure”; you’re always part of the system), need for closure (naturally uncomfortable with uncertainty; have to learn to live with it), confirmation bias, exposure effect (prefer familiar things), Hawthorne effect (people change when they’re being watched, but after a while they go back to how they were behaving), false memory (easy to confuse imagined events with real memories; every memory read is a write in light of the current context), symbolic reduction fallacy (L-mode is anxious to “symbol-away” complexity), nominal fallacy (thinking that labelling a thing means you understand it).
How to fight biases: understand that “rarely” doesn’t mean “never”, defer closure (you know the most about a project at the end of it, so don’t take decisions too early, be comfortable with uncertainty), remember that you don’t remember well. People are mainly a product of their environment and of the times. Explanation of different American generations on p. 125-131. In summary, generational archetypes are prophet (vision, values), nomad (liberty, survival, honor), hero (community, affluence) and artist (pluralism, expertise, due process). Realise where your thinking is coming from, what are your influences, and what kind of arguments you make. Try to have a diverse team so biases can catch/cancel each other. Myers Briggs Type Indicator discussion on p. 133-135. Trust intuition, but verify. If you think you have defined something, try to define the opposite.
A single intense, out-of-context classroom event can only get you started in the right direction. You need continued goals, feedback to understand your progress and approach it far more deliberately than a once-a-year course.
For any goal (desired state, usually short-term) you have in mind you need a plan, a series of objectives (steps towards that goal). Objectives should be Specific (“learn Erlang” vs. “be able to write a web server in Erlang that dynamically generates content”), Measurable (how do you know when you’re done? related to “specific”. You don’t have to see where you’re going, just a couple of meters ahead of you), Achievable (from the current state!), Relevant (does it matter to you? is it under your control?) and Time-boxed (perhaps the most important: the deadline).
Create Pragmatic Investment Plans (PIP) to learn whatever you want to learn. Major point involving managing the plan:
Have a concrete plan: devise different levels of goals (now, next year, next five years).
Diversify: make an effort to choose different methodologies, languages, industries, and non-technical stuff.
Active investment: need to be able to evaluate your plan and realistically judge how’s going. Adapt/change the plan based on that.
Invest regularly: you need to make a commitment to invest a minimum of time on a regular basis. Create a ritual, if needed.
Other techniques, like mind maps, talk to the duck and learning by teaching are mentioned in this chapter, but I’m skipping them in the summary.
And this is the end of the second part of my summary. The next one will cover the rest of the book, namely chapters “Gain experience”, “Manage Focus” and “Beyond Expertise”.
EDIT: read the third part of this summary.
Oct 11, 2011
This is the first part of my summary of “Pragmatic Thinking & Learning”, by Andy Hunt. It’s a book about how the brain works and how to take more advantage of it. It explores many interesting topics, like learning, focusing, the brain modes of operation, etc. Do note that I’ll skip many techniques/lessons in the summary, sometimes because they were less interesting for me (as in, I didn’t think they would work for me), sometimes because I already practise them. This first part will cover the introduction (in PDF), and chapters ”Journey from Novice to Expert” (in PDF) and “This is Your Brain”.
Despite advances in programming languages, techniques, methodologies, …, the defect density has remained fairly constant. Maybe we’re focusing on the wrong things: software is created in your head.
You don’t get taught, you have to learn. Everything is connected, there’s nothing in isolation, so sometimes small things can have unexpectedly larger effects.
Journey from Novice to Expert
The novice needs clear, context-free rules to operate, but an expert is ineffective when constrained by those same rules. Experts don’t just “know more” than novices, they experience fundamental differences in how they perceive the world, approach problem solving, etc. The stages of learning in the Dreyfus model are:
Novices. Have little or no previous experience in this skill area (“experience” results in a change of thinking; doing the same for years doesn’t count!). They don’t particularly want to learn, want to accomplish an immediate goal, don’t know how to respond to mistakes and are fairly vulnerable to confusion when things go awry (example of doing taxes for years on p. 20).
Advanced Beginners. Can start to break from the fixed rule set a little bit. Can try tasks on their own but have trouble troubleshooting. They want information fast (eg. API reference) and can start using advice in the correct context, but don’t have a holistic understanding and really don’t want it yet.
Competent. Can develop mental models and work with them effectively, troubleshoot problems on their own, and begin to figure out how to solve novel problems, as well as seek and take advice from experts. They’re typically described as “having initiative” or “resourceful” and tend to be in a leadership role in the team (formal or not). They’re great to have on your team because they can mentor the novices while not annoying the experts.
Proficient. Need the big picture, and thus will seek out and try to understand the larger conceptual framework around the skill. They’re frustrated by simplified information. This is the first level that can correct previous poor performance and revise their approach. They can also learn from the experience of others, which comes with the ability to understand and apply maxims.
Experts. Primary sources of knowledge and information in any field, continually looking for better methods and better ways of doing things. Statistically, there aren’t many: probably around 1-5%. Experts work on intuition, not reason. They may be completely inarticulate as to how they arrived at a conclusion. They aren’t perfect though, and have the same cognitive biases as everyone else. They’re also likely to disagree with one another.
Most people, for most skills, never get past the second stage. Plus, practitioners at a lower skill level have a marked tendency to overestimate their own abilities. Note that you want a mix of skills on a team. See “10 years to expertise” on p. 32. The dangers of overreliance on formal models (I’m skipping some in this list!):
Confusing the model with reality. It’s easy to confuse the two, but they aren’t the same.
Devaluing traits that cannot be formalised. Good problem-solving skills are critical to our jobs, but problem solving is a very hard thing to formalise.
Legislating behaviour that contradicts individual autonomy. You want thinking, responsible developers. Don’t reward herd behaviour.
Alienating experienced practitioners in favour of novices. Targeting your methodology to novices, you create a poor working environment for the more experienced.
Oversimplification of complex situations. Every project/situation is more complex than that.
Demand for excessive conformity. What worked great in your last project might be a disaster in the next one.
Insensitivity to contextual nuances. Formal methods are geared to the typical, not the particular. But when does the “typical” ever happen?
Mystification. Speech becomes so sloganised that it becomes trivial and loses meaning (eg. “we’re a customer-focused organisation”).
This is your brain
You have two “CPUs”: the linear, logical thought and language processing CPU (“L-mode”, for “linear”; the “left part of the brain”); and the searching and pattern matching CPU (The “R-mode”, for “rich”; the “right part of the brain”). They share the same bus so they can’t function at the same time.
R-mode can search “asynchronously” and come up with the response (possibly days) later. It doesn’t do any verbal processing, so the results are not verbal either (eg. trying to describe dreams). Also, it’s not under our direct concious control: as it can give answers anytime, we have to be ready to write down anything that comes up (related: everyone has good ideas, but far fewer track them; of those, even fewer bother to act on those ideas, and even fewer of those have the resources to make a good idea a success). It is very concrete, relating things as they are; it makes analogies and doesn’t require reason or known facts to process input. It’s holistic and wants to see the whole thing at once, perceiving overall patterns and structures. It’s intuitive, making leaps of insight, based on incomplete patterns, hunches, feelings or visual images. It’s very useful for software design.
Synthesis can be good for learning, see “Don’t Dissect the Frog, Build It” on p. 62. Aesthetics also make a difference, see p. 66-67. The brain is wonderfully plastic. There’s no limit to the number of skills you can learn, as long as you believe it (ie. what you think about your brain capabilities physically affects the “wiring” of the brain itself).
And that’s all for now. The next part will cover chapters ”Get in Your Right Mind” and “Debug Your Mind”.
EDIT: read the second part of this summary.
Jul 22, 2008
Some time ago, Opera announced the Opera Web Standards Curriculum project. It’s a very interesting collection of articles that can be used as “curriculum” to learn about web development. It gets extra geeks points for using a Creative Commons license for the articles themselves. Even the W3C mentioned it
:-)I just found some time to have a look at it, that’s why I’m posting now
The other news is that finally the Opera QA blog is online, and has the first non-hello-world-article (written by yours truly), “Continuous Integration: Team Testing”. I’m very excited about this, because it’s the first time I’ll participate directly in a company blog, and because the IT world needs more (and better) QA, so hopefully we’ll be able to spread the word and make the world a better place
Jun 15, 2008
Some days ago, Arve posted a very interesting link in Twitter: Turn Your Point-and-Shoot into a Super-Camera. It was about something called CHDK (Canon Hacker’s Development Kit), which is a non-official firmware enhancement for many Canon cameras.
It sounds pretty scary, but actually it’s really safe and easy to use: you just copy some files into your memory card, and ask the camera to upgrade the firmware via some menu option. The awesome part is that it only “upgrades” a copy in memory, so if you simply turn off the camera, the next time everything is back to normal. Of course there are options to load it on startup if you’re happy with it.
The goodies: saving in RAW format, some new menu options, more information on the OSD, configurable OSD, BASIC scripting, and even games (Sokoban and Reversi). One of the features that caught my attention in the article was a special mode for motion detection, that apparently works well for making pictures of lightning strikes. And it’s actually a user-written script, how awesome is that?
I haven’t played that much with it yet, but I have tried and it works as advertised (YMMV). I can’t wait to use it more, and maybe even try some silly BASIC program.
Thanks a lot Arve!