This tastes incredible and gives me sustained energy. All the ingredients are anti-inflammatory. So good and healthy!
- 1/4 cup of almonds (soaked for several hours)
- 1 cup of coconut water
- 1/2 cup of water + ice
- 1 (or 2) medjool date
- 2 teaspoons of mesquite powder
- 1/2 teaspoon of turmeric powder
- 1/2 teaspoon of cinnamon powder
- 1/2 teaspoon of ginger powder and/or fresh ginger
- 1/2 teaspoon of vanilla powder
- A pinch of nutmeg
- A pinch of cloves
- 1 tablespoon of coconut oil
i’ve had the good fortune to work on a green field Rails project. Here are some of the “i would not want to do without” tools used on this project
- ruby 1.9.3 - so much faster than 1.8. wow.
- rails 3.2 – rails just keeps getting better and better.
- mini-profiler –everyone should want a fast app. found lots of unoptimized queries.
- sass — sass makes css fun!
- rspec — i love the rspec DSL.
- capybara — super useful for our request specs.
- devise – it works. easy to use.
- vcr – essential for service tests. call out once, but cache after that.
- cancan — great role system, easy to use.
- kaminari – works great for paging (along w/ jquery.pageless)
- sendgrid — send notification emails, easy w/ sendgrid
- librato — low level metrics like rows written on some models,
- machinist — love blueprints that are either persisted to db or not. easy to use.
- redis — super fast key value storage. great for caching.
- resque & resque-scheduler. for asyn and cron jobs, easy to use, fast.
- simple_form — a great improvement over standard Rails forms
- airbrake. you want to know when exceptions happen!
- activeadmin. most everyone needs a admin backdoor to their app right? here it is!
Neat stuff that we use that i’m not huge on
- inherited_resources — i prefer seeing the controller actions explicitly. it makes peer review on-boarding new people easier. less magic.
Other essential tools & practices
- a great, easy to use CI system. We use CircleCI. nearly turnkey and hooks into github nicely.
- incremental checkins. We use git, github, topic branches, pull requests, and ey cloud deployment commands.
- peer review of pull requests: either the code is pair programmed or the pull request is peer reviewed prior to merging into master
- Pivotal Tracker. A great simple tool that does the job.
- NewRelic: essential for app performance monitoring.
- Mixpanel: great for funnel analysis. we measure all activities in our app and important properties for those activities.
- Twitter bootstrap. it’d be great to have the luxury of a talented designer, but we didnt. this did a great job. it’s important to get a designer in there eventually, or your app will look like a twitter bootstrap app. this might be ok for a captive audience, but not mass consumption.
Using this great toolset has made this project a joy to work on. Hope this helps others.
Our development team knows how to have fun. wahoo!!! What’s life but lots of tiny fun moments strung together? I think that doing non-work, outdoor things like this together creates the most durable of team bonds. And helps encourage each of us to get regular (outdoor) exercise which makes for stronger brains, body, & smiling personalities. Fun + stronger body & brain + team bonds equals a great place to work!
Here are a few pics from a recent thursday evening mountain bike adventure. We rode together, we helped each other when there was #Fail, we had fun with each other. Times like this strengthen the team.
Here’s a slide deck on code smells in ruby I recently put together to show our development team.
Once everyone has an idea of why understanding and reducing code smells is important, then the benefit gets distributed when others use knowledge in pull request reviews.
made a open source contribution to the Chronic gem last night. as always, feels good to help out the community. we use other people’s open source work, we give back.
I’ve had a long history of working on software projects. This history started off in C & then moved to Pascal, C++, C#, and now to Ruby/Rails. I’ve worked in consulting, IT, a handful of big name software shops (Microsoft, Amazon, RealNetworks), and smaller name software shops (Symyx, G5). I’m currently very pleased with the project i’m on, and wanted to share some of my observations of what i think makes this great software project, and a few other observations I’ve learned along the way. I consider the below points a team & project recipe for keeping good people happy and delivering value. My current company is G5. My current project is G5 Reputation Manager
People. Keep teams small, focused, autonomous.
Keep the team small Small teams collaborate and focus better. Hire people that can communicate. Keep people that can be entrusted with autonomy. As much as possible, separate corporate minutiae from your project. Find another building to locate to if necessary. In hiring, I’ve seen much better team dynamics and productivity by avoiding the “ninjas, rock stars, hackers, big egos”. You can tell a lot about people thru their twitter feeds. Try to hire a developer on contract for 6 months before bringing in full time. Probe candidates on how interested they are in continual self-improvement. For teams, I think the ideal team size is 2 developers (4 max) and one business owner. That’s it. No QA team to throw code over the fence to, no PM team. The strongest of these team members is the lead. The lead keeps on top of the team’s cadence and best understands the business problem. The lead inspires great work from the team.
Tools. Stay mainstream, lightweight…and delighted!
I am not religious about Ruby & Rails and I prefer to not work with people that consider their tool a godsend and refuse to consider others. That said, i’m super happy w/ the expressiveness and beauty of the ruby language. The value of this cannot be understated. It never ceases to amaze me how deep the Rails community is…there’s a gem for nearly anything you might want to do. If not, build it and contribute! On our Ruby Rails project, I’m using a mainstream toolset in our stack that works great (& is invaluable to my skillset): Pivotal Tracker, Rails 3.2.3, Ruby 1.9.3, Rubymine (vi), git, mysql, redis). You want to maintain rhythm on delivering value to your customers, not spending days worrying why your CI server isnt working w/ your SCM. Stay on current version w/ ruby and rails! it gets harder to upgrade in Rails the further you fall behind. A great suite of tests is invaluable for upgrades. Use frameworks (like Twitter bootstrap) to speed things along. Use a collaboration tool like Campfire or FlowDock for team communication (but turn off your growl notifications!) What i like about FlowDock is the message inbox & the git/airbrake-rss/PivotalTracker integration. We use AirBrake for exception notifications. This tool has been great to show us where test coverage is needed and where our customers might be experiencing repeated problems.
Agile. Stay lean, short iterations, measure and pivot.
Start the project with a MVP. Make your best stab at scratching a 10X itch. Build in ways to measure the features your customers are using. Pivot, improve, or kill features or direction as early as possible. What good is it to spend 6 months of your team’s time to build a product that isn’t scratching the right market itch? Be ruthless about eliminating waste: don’t do standups if you’re not getting value from them; don’t insist on pair programming if your team doesn’t favor it. Stick to the essence of agile: short iterations, adaption, quick feedback. The rest will work out.
Work environment. Kill the distractions. Let in natural light.
Don’t skimp on a quality work environment. Distractions are the biggest enemy of productivity. Give developers a quiet, distraction free workspace with lots of natural light. Natural light improves mood, health, and productivity. Provide a walking desk and standup pairing stations. Also, most developers love to work at home occasionally. If working at home is producing quality commits to git, i’m all for it. If a developer goes dark, nip that problem early.
Quality. It’s not optional.
When we started this project, even under big pressure to deliver yesterday, we started it off not compromising quality. All code is reviewed, either thru pair programming or git pull request reviews. We measure code coverage (simplecov) every few weeks to check for missing holes. We use flog to measure code complexity and refactor the trouble spots. Our project code is idiomatic Ruby & well-tested…mostly thru isolated unit tests, and thru some higher level acceptance tests. I prefer TDD, but dont insist on it. With TDD, you know your tests are good and you know you’ve written just enough code to pass the tests. But, depending on the context, sometimes I like writing tests after the code. I think it’s important to allow some freedom in how developers like to work. No compromises on making sure your tests are fast! We do this by isolate business code from framework code as much as possible, isolated unit test the business code and integration test the stack. Tests are written to the same quality standard as production code. Make sure everyone on your team is experienced in recognizing code smells, using design patterns, understands the importance of tests. Dont be afraid to call out quality violations. Set the quality bar high early on.
Leadership. Ya gotta have it.
The self organizing team is a myth. I’ve seen countless examples of great individual skill assembled as a team flounder without a clear leader. Find, cultivate, and reward developers that show a propensity to lead, understand the business, and stay on top of technology. Rails programmers can be found at any time. But a strong technical leader is worth their weight in gold.
Support the community. Find a way to contribute to open source.
Imagine life with ruby, rails, and the thousands of great gems out there. We are using open source in our project and we owe something back. It feels good to contribute.
Organizational support. A must have.
It’s exciting when your CEO comes by your office and gives you real customer feedback on your project. You’ve scratched a major itch! It’s also exciting when your CTO pays you a personal visit at your home to let you know about a major customer event evangelizing your project. It’s been a boon for us that all our project’s stakeholders have aligned priorities.
Deployment. Use the cloud.
We’re using EY cloud. Easy setup, easy deploys from git, and the best thing is easy spin up of staging clones to do topic branch testing. When a topic branch is done, it’s reviewed, merged, and deployed. It’s a joy that i can finish a topic branch, spin off a clone of production and test it there before deploying to production.
Cadence. Keep it reasonable & w/ smart use of time-boxing.
Give developers work-time/place flexibility and minimize distractions. If > 40 hours are necessary, offer developers the option to be paid by the hour or gain a meaningful equity stake. Dont expect more than a 8 hour day. Even better is to measure on quality of output, not hours worked, and dont be a time-card puncher. Treat your team with dignity and respect for their families and wellbeing. Use meaningful deadlines & showcase-driven time-boxing (e.g., a trade conference where your product is being demonstrated) to maintain workable pressure and then celebrate when you’ve crossed the finish line. But dont over use the time box or it will suck your team’s soul dry and you’ll find your developers quickly updating their linkedIn profiles.
Rest. Enjoy. And celebrate.
Humans are hardwired to pulse. Pay attention to your physiological needs. Take frequent breaks. I like Pomodoro as a tool to encourage focus and force me to take frequent breaks. Drink lots of water, eat healthy, and exercise every day. Sleep as much as your body needs. Relax. Your brain and body will thank you. When you get great news from inside or outside your company, celebrate! Do fun outdoor things with your team mates that dont involve coding! Take frequent vacations. Enjoy being alive and productive.
I hope others find this useful. p.s. I am indebted to my friend, Rails mentor, & co-worker Chris Kraybill, CTO at G5.
This recipe is a synthesis of a various recipes i’ve seen on making cobblers. i like mine to have less sugar so that you can really taste the berries.
- 3/4 c butter
- 2-3 cups of mixed berries
- 1 1/2 c flour
- 1 t baking powder
- 1/3 cup whole milk
- 1/2 cup warm water
- 1/2 cup raw cane sugar
- 1 T cinnamon
- (opt) 1/4 c chopped crystalized ginger (in addition to where cinnamon is used)
- (opt) 1/4 c chopped pecans (in addition to where cinnamon is used)
- (opt) replace 1/2 cup of the flour with oats ground in a food processor
Mix the butter in with the flour & baking powder. Add in the milk, mix into a ball, kneed a few times. Put 1/3 of the dough on the bottom of the disk, sprinkle with 1/2 of the cinnamon.
Toss in the berries. Sprinkle the rest of the cinnamon.
Add the rest of the dough to make the cap. Mix the warm water & sugar, driizzle over the top.
Bake at 350 for 45 mins. Sprinkle the top w/ a bit of sugar and bake for 20 more mins.
Enjoy with a good quality vanilla ice cream!
Note: another good fruit combination is pear and mango. add blueberries too!