Monday, February 27, 2012
project 2 + n
In a different city, doing different things
DevOps!
Modifying jenkins plugins
Working with JUnit tests which are not actually unit tests
Scripting against the Jenkins api
Systems-style thinking
reading lots of new books, most of which are about half code
Sunday, September 25, 2011
Project 2, going to be here a while
The learning curve was tremendous. Learning an older version of Rails, learning the monkeypatches on it, learning how to deal with metaprogramming from a refactoring perspective. Learning a new editor (SUblime, which I've grown to like quite a bit for dealing with really large files)
Learning about the team, and the team's customs (Jukebox for music was an interesting one...)
Environment issues, DNS server issues, lots and lots of Redis/resque issues.
Learning to take notes in a notebook rather than in evernote
Learning to take hipster jokes with grace and style- or at least without devolving into Godwin's law.
Reading innumerable books on the train.
Meetups- Ruby, Clojure, JavaScript, female developers (sorely needed), ChiSC (discontinued?)...
Setting up Bundler for a largish established app with custom local gems
Learning about the team, and the team's customs (Jukebox for music was an interesting one...)
Environment issues, DNS server issues, lots and lots of Redis/resque issues.
Learning to take notes in a notebook rather than in evernote
Learning to take hipster jokes with grace and style- or at least without devolving into Godwin's law.
Reading innumerable books on the train.
Meetups- Ruby, Clojure, JavaScript, female developers (sorely needed), ChiSC (discontinued?)...
Setting up Bundler for a largish established app with custom local gems
Tuesday, May 31, 2011
Project 1, rolled-off.
Friday was my last day on my first TW project. What have we learned?
Handover is very important, but with practice it can be done well with little effort. One centralized repository for knowledge is good, although in this case it's more like a combination of Mingle and direct email.
Turning a temporary build server off and back on again will teach you everything about how to set up new ones- also, where the script to do it is. Scripts are wonderful. I think that automating everything using Puppet would be even more wonderful.
Servers without enough space on them are an enormous nuisance when testing giant data import tasks. How to fix this: ask nicely. Also, back channels of communication.
Never assume that you know what an error message means (in Resque tasks, one task can fail because of a parsing error, without the rest of them failing. This happens when there is a small anomaly in the data. You don't need to fix the anomaly in order to finish running the test.)
Developers (well, me) are much happer when they get comfortable chairs, and floors with no holes for chairs to fall into.
git:// vs git@ is an important distinction: the first one gets a read-only copy, the second gets read-and-write. Your build server needs the first one, your development machine needs the second one. The second one throws interesting authentication errors against some firewalls. (I haven't figured out exactly what happened there yet.) When git clone fails and you're in a hurry, you can just scp over the most recent version from a different machine. This is deeply suboptimal because git pull will fail either consistently or sporadically, depending on your firewall configuration.
The db/data directory in a rails app is my favorite because you can auto-generate rake data import tasks by putting things in it.
RHEL (RedHat) 5.5 has no package for git. Use wget, configure, and make. Pick your favorite package version. http://kernel.org/pub/software/scm/git/
Always put your hardware diagrams and reference scripts in the repository.
If you have problems with unstable commits, label the obviously unstable and obviously stable ones. Git tag is a great command.
Making a diagram of iOS certificate signing is difficult, can be done in many different ways, and although ideally it would explain itself that is so far not the case; it's just a very useful visual aid to a question-answer session.
Mongo shell is a lot of fun.
Hotdogging someone's computer by making it easy to lock the screen is acceptable. On OSX, do this by:
System Preferences, desktop/Screensaver/, hot corners, put display to sleep (in one of them). Then, System Preferences, Security, Require password immediately after sleep or screensaver begins.
"Hotdogging" is a colloquial term for "doing something to an unlocked computer to point out to the owner of that computer that they shouldn't leave their computer unlocked"
If you have trouble hearing on the phone, there are several easy partial fixes:
Evernote will take over your life and become your primary external brain storage, but it will make you soooo on top of things. So it might be worth it. I would recommend using the opensource clone Nevernote instead; it has cooler features.
Pre-built secure RPMs exist (you'll probably want to make them yourself?) and you use them for your production machines. To prevent surprises, also use them in advanced testing.
Screenshots are beautiful, essential things when you are working in distributed teams. They reveal communication empty spots which you might have otherwise discovered at a less convenient time. Send them daily. Request them daily. They don't have to be fancy.
Rands in Repose wrote a very excellent book called Managing Humans and as a developer I enjoyed reading it; it discusses some very useful things about communication styles which were directly relevant to things I was having trouble with. (See above re: phone calls and distributed teams)
Handover is very important, but with practice it can be done well with little effort. One centralized repository for knowledge is good, although in this case it's more like a combination of Mingle and direct email.
Turning a temporary build server off and back on again will teach you everything about how to set up new ones- also, where the script to do it is. Scripts are wonderful. I think that automating everything using Puppet would be even more wonderful.
Servers without enough space on them are an enormous nuisance when testing giant data import tasks. How to fix this: ask nicely. Also, back channels of communication.
Never assume that you know what an error message means (in Resque tasks, one task can fail because of a parsing error, without the rest of them failing. This happens when there is a small anomaly in the data. You don't need to fix the anomaly in order to finish running the test.)
Developers (well, me) are much happer when they get comfortable chairs, and floors with no holes for chairs to fall into.
git:// vs git@ is an important distinction: the first one gets a read-only copy, the second gets read-and-write. Your build server needs the first one, your development machine needs the second one. The second one throws interesting authentication errors against some firewalls. (I haven't figured out exactly what happened there yet.) When git clone fails and you're in a hurry, you can just scp over the most recent version from a different machine. This is deeply suboptimal because git pull will fail either consistently or sporadically, depending on your firewall configuration.
The db/data directory in a rails app is my favorite because you can auto-generate rake data import tasks by putting things in it.
RHEL (RedHat) 5.5 has no package for git. Use wget, configure, and make. Pick your favorite package version. http://kernel.org/pub/software/scm/git/
Always put your hardware diagrams and reference scripts in the repository.
If you have problems with unstable commits, label the obviously unstable and obviously stable ones. Git tag is a great command.
Making a diagram of iOS certificate signing is difficult, can be done in many different ways, and although ideally it would explain itself that is so far not the case; it's just a very useful visual aid to a question-answer session.
Mongo shell is a lot of fun.
Hotdogging someone's computer by making it easy to lock the screen is acceptable. On OSX, do this by:
System Preferences, desktop/Screensaver/, hot corners, put display to sleep (in one of them). Then, System Preferences, Security, Require password immediately after sleep or screensaver begins.
"Hotdogging" is a colloquial term for "doing something to an unlocked computer to point out to the owner of that computer that they shouldn't leave their computer unlocked"
If you have trouble hearing on the phone, there are several easy partial fixes:
- use Skype (better sound quality)
- email the topics that you heard discussed to someone that was also on the call and ask them to fill in gaps
- get a hearing test
Evernote will take over your life and become your primary external brain storage, but it will make you soooo on top of things. So it might be worth it. I would recommend using the opensource clone Nevernote instead; it has cooler features.
Pre-built secure RPMs exist (you'll probably want to make them yourself?) and you use them for your production machines. To prevent surprises, also use them in advanced testing.
Screenshots are beautiful, essential things when you are working in distributed teams. They reveal communication empty spots which you might have otherwise discovered at a less convenient time. Send them daily. Request them daily. They don't have to be fancy.
Rands in Repose wrote a very excellent book called Managing Humans and as a developer I enjoyed reading it; it discusses some very useful things about communication styles which were directly relevant to things I was having trouble with. (See above re: phone calls and distributed teams)
Tuesday, April 19, 2011
"Why do I need to restart my iPad to install this app?"
I have no idea, but it's happened to me... development apps signed with correct UDIDs.
Sunday, April 3, 2011
What are you doing in there?
My first few weeks at ThoughtWorks have been interesting. When I first got back from India, I spent a weekend as a jetlagged zombie thanks to the 12.5 hours of time difference, but by Monday I was mostly functional and by Tuesday I was good to go.
My first Monday back in the USA I went in to the office, met up with my fellow Chicagoans from TWUXX, and had a series of chats with various people about our experiences and our future assignments. For a week, we mostly sat at the beach (a table where people not on assignment tend to sit... it has a palm tree ^.^) We spent some time looking at making a command-line interface for Mingle. It was all our own project, and we didn't make that much headway, although I learned a lot of interesting things about the structure of Ruby gems.
On the second week we worked on a small Rails app with some interesting algorithm problems- this was an assignment, not just a project that we happened to be working on. We were trying to refine the theory behind some not completely understood complexities in the algorithms. Around the middle of the week, I was taken off the project, so I didn't get to see the delivery of the first iteration... but I hear it was good!
I was now shadowing DevOps on a project in Chicago. I experienced conceptual overload several times in my first day there... not only did I learn about new tools, I learned about new concepts and new fields of thought. I enjoyed it very much.
I learned about the brother build systems Hudson and Jenkins and how they were different from Go/CruiseControl, and servers and server structure and I had my first introduction to CentOS, which is a clone of RedHat. I learned how Selenium, a web application testing system, can be run headless on servers. I began to increase my understanding of the structure and means of manipulating of firewalls.
I learned more about databases and mySQL, as well as becoming competent with ssh keys and server access. I learned which directories (on the servers for this particular project) were used for what. I gained an understanding of the complicated filetree of the repository containing the code that our servers were running. I learned what JIRA is (bug/request tracking software), and how useful they can be... and how many fields there are to fill out!!
After some time, I was given a new assignment, in a nearby location... as a DevOps person in my own right, setting up a simple build system. Now I'm learning to use Frank, which is similar to Selenium but for testing iOS applications.
Not only that, but in my copious spare time, I'm working with XNA 4.0 and I've been reading up on the OpenKinect library with an eye to doing something cool. In my personal spare time I've been trying to get my laptop to detect and understand the input from my SparkFun RFID kit, but it looks like I'll need to use Windows unless I discover something new.
Also I bought a new phone, a G2, and I'm enjoying learning my way around its interface and playing with apps.
My first Monday back in the USA I went in to the office, met up with my fellow Chicagoans from TWUXX, and had a series of chats with various people about our experiences and our future assignments. For a week, we mostly sat at the beach (a table where people not on assignment tend to sit... it has a palm tree ^.^) We spent some time looking at making a command-line interface for Mingle. It was all our own project, and we didn't make that much headway, although I learned a lot of interesting things about the structure of Ruby gems.
On the second week we worked on a small Rails app with some interesting algorithm problems- this was an assignment, not just a project that we happened to be working on. We were trying to refine the theory behind some not completely understood complexities in the algorithms. Around the middle of the week, I was taken off the project, so I didn't get to see the delivery of the first iteration... but I hear it was good!
I was now shadowing DevOps on a project in Chicago. I experienced conceptual overload several times in my first day there... not only did I learn about new tools, I learned about new concepts and new fields of thought. I enjoyed it very much.
I learned about the brother build systems Hudson and Jenkins and how they were different from Go/CruiseControl, and servers and server structure and I had my first introduction to CentOS, which is a clone of RedHat. I learned how Selenium, a web application testing system, can be run headless on servers. I began to increase my understanding of the structure and means of manipulating of firewalls.
I learned more about databases and mySQL, as well as becoming competent with ssh keys and server access. I learned which directories (on the servers for this particular project) were used for what. I gained an understanding of the complicated filetree of the repository containing the code that our servers were running. I learned what JIRA is (bug/request tracking software), and how useful they can be... and how many fields there are to fill out!!
After some time, I was given a new assignment, in a nearby location... as a DevOps person in my own right, setting up a simple build system. Now I'm learning to use Frank, which is similar to Selenium but for testing iOS applications.
Not only that, but in my copious spare time, I'm working with XNA 4.0 and I've been reading up on the OpenKinect library with an eye to doing something cool. In my personal spare time I've been trying to get my laptop to detect and understand the input from my SparkFun RFID kit, but it looks like I'll need to use Windows unless I discover something new.
Also I bought a new phone, a G2, and I'm enjoying learning my way around its interface and playing with apps.
Friday, April 1, 2011
installing git on CentOS 5.3
(required in order to get many many other useful things)
sudo rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
sudo yum install git
that link will change depending on your version of CentOS, and of course it changes over time. Look it up at https://fedoraproject.org/wiki/EPEL
sudo rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
sudo yum install git
that link will change depending on your version of CentOS, and of course it changes over time. Look it up at https://fedoraproject.org/wiki/EPEL
Thursday, March 17, 2011
VIrtualBox fullscreen: my favorite guide
http://digitizor.com/2009/05/26/how-to-install-virtualbox-guest-additions-for-a-linux-guest/
Labels:
ubuntu,
virtualbox
Thursday, March 3, 2011
gem list error
I've been getting this error frequently during or after running a process which uses Ruby intensively. So far I have no solution other than restart. It also affects all other gem commands, including gem --version.
$ gem list
line 5: [path]: Argument list too long
line 5: [path]: Unknown error: 0
I'm still looking into how to fix this.
$ gem list
line 5: [path]: Argument list too long
line 5: [path]: Unknown error: 0
I'm still looking into how to fix this.
Labels:
ruby
Tuesday, March 1, 2011
Monday, February 28, 2011
Friday, February 25, 2011
add "mate" to your path in OSX (to call TextMate)
To add "mate" to the path of OSX (i.e TextMate) you could do stuff in the terminal, or you could do
Help > Terminal Usage > Create Link
and achieve the same result. Sometimes the GUI is useful.
on the beach
I'm in Chicago, on the "beach" with some other TWUXXers getting our environments set up for next week, when we're on a small project spike... using Rails 3.0, JBehave, some other stuff...
On an unrelated note, I'm trying to get Bugzilla installed and configured. Conclusion: why are we using this anyway?
I went to a RoR101 session at lunch today... was interesting but the audience was very diverse in knowledge level.
The grocery store convenient to the Aon center is http://www.bockwinkels.com/
On an unrelated note, I'm trying to get Bugzilla installed and configured. Conclusion: why are we using this anyway?
I went to a RoR101 session at lunch today... was interesting but the audience was very diverse in knowledge level.
The grocery store convenient to the Aon center is http://www.bockwinkels.com/
installing BugZilla
http://bugzilla.darwinports.com/
http://www.bugzilla.org/docs/2.18/html/installation.html
First, install MacPorts
go to /opt/local/bin
install https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=20719 <- must be registered as a dev w Apple to do this
sudo port install bugzilla
run the ./checksetup.pl file is in /opt/local/www/Bugzilla
follow instructions...
current error: Error in tempfile() using data/params.XXXXX: Parent directory (data/) does not exist at Bugzilla/Config.pm line 313
way to solve this error: follow the instructions in 5. in QUICKSTART and create the database
(I haven't solved this yet)
- get appleid
- get xcode and therefore db46
- continue installing bugzilla
Configuring db46
Error: db46 requires the Java for Mac OS X development headers.
Error: Download the Java Developer Package from: <https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=20719>
Error: Target org.macports.configure returned: missing Java headers
http://comments.gmane.org/gmane.os.apple.macports.user/22266
"Apple's most recent security update prior to Mac OS X 10.6.5 (presumably included in 10.6.5 also) deletes a file that was previously part of the OS, and is now only part of that development package. We don't know why Apple made this change, only that db46 and a handful of other ports break without it, so we detect this and advise you how to fix it."
http://yoodey.com/how-fix-db46-problem-macport-installation-or-install-db46-mac-os-x-1065
Bugzilla Quick Start Guide
==========================
(or, how to get Bugzilla up and running in 10 steps)
Christian Reis <kiko@async.com.br]]>
This express installation guide is for "normal" Bugzilla installations,
which means a Linux or Unix system on which Apache, Perl, MySQL or PostgreSQL
and a Sendmail compatible MTA are available. For other configurations, please
see Section 4 of the Bugzilla Guide in the docs/ directory.
1. Decide from which URL and directory under your webserver root you
will be serving the Bugzilla webpages.
2. Unpack the distribution into the chosen directory (there is no copying or
installation involved).
3. Run ./checksetup.pl, look for unsolved requirements, and install them.
You can run checksetup as many times as necessary to check if
everything required has been installed.
These will usually include assorted Perl modules, MySQL or PostgreSQL,
and a MTA.
After a successful dependency check, checksetup should complain that
localconfig needs to be edited.
4. Edit the localconfig file, in particular the $webservergroup and
$db_* variables. In particular, $db_name and $db_user will define
your database setup in step 5.
If you want to change platforms, operating systems, severities and
priorities, this can also be done in localconfig at this time.
5. Using the name you provided as $db_name above, create a MySQL database
for Bugzilla. You should also create a user permission for the name
supplied as $db_user with read/write access to that database.
If you are not familiar with MySQL permissions, it's a good idea to
use the mysql_setpermission script that is installed with the MySQL
distribution, and be sure to read Bugzilla Security - MySQL section
in the Bugzilla Guide or PostgreSQL documentation.
6. Run checksetup.pl once more; if all goes well, it should set up the
Bugzilla database for you. If not, return to step 5.
checksetup.pl should ask you, this time, for the administrator's
email address and password. These will be used for the initial
Bugzilla administrator account.
7. Configure Apache (or install and configure, if you don't have it up
yet) to point to the Bugzilla directory. You should enable and
activate mod_cgi, and add the configuration entries
Options +ExecCGI
AllowOverride Limit
DirectoryIndex index.cgi
to your Bugzilla <Directory> block. You may also need
AddHandler cgi-script .cgi
if you don't have that in your Apache configuration file yet.
8. Visit the URL you chose for Bugzilla. Your browser should display the
default Bugzilla home page. You should then log in as the
administrator by following the "Log in" link and supplying the
account information you provided in step 6.
9. Scroll to the bottom of the page after logging in, and select
"parameters". Set up the relevant parameters for your local setup.
See section 4.2 of the Bugzilla Guide for a in-depth description of
some of the configuration parameters available.
10. That's it. If anything unexpected comes up:
- read the error message carefully,
- backtrack through the steps above,
- check the official installation guide, which is section 4 in the
Bugzilla Guide, included in the docs/ directory in various
formats.
Support and installation questions should be directed to the
mozilla-webtools@mozilla.org mailing list -- don't write to the
developer mailing list: your post *will* be ignored if you do.
Further support information is at http://www.bugzilla.org/support/
Tuesday, February 15, 2011
Iteration 4, Tues
Rewriting functional tests and Twist tests after adding universal login requirement to all application functionality is interesting and it depends on how you're implementing it. This will be an ongoing debate tomorrow.
The option to create a custom aspect ratio in Picasa is very very useful for creating images and banners of precisely the correct size for various websites, in this case a 760x100 Etsy store banner.
The option to create a custom aspect ratio in Picasa is very very useful for creating images and banners of precisely the correct size for various websites, in this case a 760x100 Etsy store banner.
Labels:
jetty,
learningjournal,
TWU
Valentines Day in India
For Valentines Day, the majority of TWUers went to the restaurant Healthy Affairs, which is affiliated with the Sukrupa organization. The tablecloths were made by Sukrupa Creations, as were the lovely red centerpiece candles, as was the epic 3ft tall candle in the entranceway.
Healthy Affairs recently got their liquor license, and they sell local champagne and wine. I very much enjoyed the champagne, and I hear that the red wine was quite nice. The special valentines day menu was delicious. Personally, I had the garlic shrimp (i.e. prawns), the watermelon and mint mocktail, a non-veg salad (delicious mozzarella cheese, small pieces of tart green apples, firm watermelon balls, chopped head lettuce, and basalmic vinegar), and the pineapple spiced chicken, followed with a desert of strawberries dipped in chocolate and caramel.
The band that played was called The Windmills, and they did excellent renditions of love songs, mostly in English and with several great Beatles-era classics. On the walls there was an art exhibition by local Bangalore cartoonists Balraj KN and Rasheed Kappan.
healthyaffair@gmail.com
reservations or delivery: +91 80 41255073
Address:
2041, 1st Cross, 17th Main, HAL 2nd Stage, Indra Nagar, Bangalore-560008
Healthy Affairs recently got their liquor license, and they sell local champagne and wine. I very much enjoyed the champagne, and I hear that the red wine was quite nice. The special valentines day menu was delicious. Personally, I had the garlic shrimp (i.e. prawns), the watermelon and mint mocktail, a non-veg salad (delicious mozzarella cheese, small pieces of tart green apples, firm watermelon balls, chopped head lettuce, and basalmic vinegar), and the pineapple spiced chicken, followed with a desert of strawberries dipped in chocolate and caramel.
The band that played was called The Windmills, and they did excellent renditions of love songs, mostly in English and with several great Beatles-era classics. On the walls there was an art exhibition by local Bangalore cartoonists Balraj KN and Rasheed Kappan.
healthyaffair@gmail.com
reservations or delivery: +91 80 41255073
Address:
2041, 1st Cross, 17th Main, HAL 2nd Stage, Indra Nagar, Bangalore-560008
Labels:
TWU
Monday, February 14, 2011
Iteration 4, Mon
Jetty login basic authorization is not actually secure; it only concatenates the username and password and base 64 encodes. Anything that can be done in XML can be done in Java, but shouldn't always be.
If you get into hashes, you're still not particularly secure. Only when you start using salts in your hashes is it possible to escape the problem of malicious rainbow tables. And if your project is open source, then it's unwise to include your salt in the source which is going open, unless your salt generator is unpredictable. Cookie based sessions over SSL will follow logically when true security is needed.
Since iteration 1 is drawing to a close, we're planning to branch and continue development after we achieve our release candidate, so the candidate can be tested end to end.
I've been playing with EC2 for things unrelated to work, namely the git bash recursion script Maypole... which is still very basic.
Getting a working handover for the next team is an interesting problem. In general, good code explains itself, but the same doesn't really apply to build systems and to configuring local development systems.
Future TWUers: if you have Windows, dualboot Linux, ideally before development starts so you won't have to do everything twice. Keep in mind that Sonar and Twist sometimes don't keep up with refactorings of package structure and paths. Pay attention to our build monitor. And always, always check and update Mingle. Get everyone to the client site as early in the project as possible. Always invite the devs to the showcase but don't require attendance. Try to stack informative sessions immediately after standup. And remember that the buffet at the Mercurial is the best lunch you can find. Ask for feedback- it's pull, not push. Have a code review weekly and review your technical debt, but timebox it.
Apache Ivy is a .jar dependency manager, and it solves a lot of problems where we need several versions of one package for different functionalities. Without Ivy, you can get difficult to track errors if your .jars are called in an unexpected order.
If you get into hashes, you're still not particularly secure. Only when you start using salts in your hashes is it possible to escape the problem of malicious rainbow tables. And if your project is open source, then it's unwise to include your salt in the source which is going open, unless your salt generator is unpredictable. Cookie based sessions over SSL will follow logically when true security is needed.
Since iteration 1 is drawing to a close, we're planning to branch and continue development after we achieve our release candidate, so the candidate can be tested end to end.
I've been playing with EC2 for things unrelated to work, namely the git bash recursion script Maypole... which is still very basic.
Getting a working handover for the next team is an interesting problem. In general, good code explains itself, but the same doesn't really apply to build systems and to configuring local development systems.
Future TWUers: if you have Windows, dualboot Linux, ideally before development starts so you won't have to do everything twice. Keep in mind that Sonar and Twist sometimes don't keep up with refactorings of package structure and paths. Pay attention to our build monitor. And always, always check and update Mingle. Get everyone to the client site as early in the project as possible. Always invite the devs to the showcase but don't require attendance. Try to stack informative sessions immediately after standup. And remember that the buffet at the Mercurial is the best lunch you can find. Ask for feedback- it's pull, not push. Have a code review weekly and review your technical debt, but timebox it.
Apache Ivy is a .jar dependency manager, and it solves a lot of problems where we need several versions of one package for different functionalities. Without Ivy, you can get difficult to track errors if your .jars are called in an unexpected order.
And remember... there will always be "The technical TWer who likes to write their own and doesn't believe in anything."
Labels:
learningjournal,
TWU
Friday, February 11, 2011
teaching programming
Spent part of today teaching kids to program using Scratch. I think that it's an excellent learning tool for young beginning programmers, to introduce basic if else logic and cause-effect ideas. It also has more advanced capabilities like variable manipulation.
Labels:
TWU
Thursday, February 10, 2011
Iteration 3, Thurs
Today I learned lots about PayPal in India and Etsy in general. I believe that the government of India is trying to force market pressure for a homegrown version of PayPal.
There is a Javascript plugin for intelliJ called JS Test Driver. It is useful although for small projects I guess it's just as good to use TextMate if you have it.
I also learned (from a place where I previously worked) that searching email logs can answer most of your "but what is my username?" questions.
Good client relations are very important. Sometimes this means giving small children a stuffed lion and some tennis balls, and refraining from ordering pizza. Other times, it means practicing endlessly for a short presentation so as to be ready for as many questions as possible.
There is a Javascript plugin for intelliJ called JS Test Driver. It is useful although for small projects I guess it's just as good to use TextMate if you have it.
I also learned (from a place where I previously worked) that searching email logs can answer most of your "but what is my username?" questions.
Good client relations are very important. Sometimes this means giving small children a stuffed lion and some tennis balls, and refraining from ordering pizza. Other times, it means practicing endlessly for a short presentation so as to be ready for as many questions as possible.
Labels:
learningjournal,
TWU
Wednesday, February 9, 2011
Iteration 3, Weds
UX/UI is complicated to describe and implement. JavaScript is fun, but takes lots of lines of code. CSS is fantastic but you can fiddle with it forever.
Inspiring speakers are inspiring because they are involved in their topic.
KFC in India has veg options.
Pecha Kucha are awesome.
Inspiring speakers are inspiring because they are involved in their topic.
KFC in India has veg options.
Pecha Kucha are awesome.
Labels:
learningjournal,
TWU
Subscribe to:
Posts (Atom)