Nina Mehta, a designer at Pivotal Labs, discusses tips in tricks for collaborating between developers and designers while continuing with Agile methodologies.
WWDC key points
new in iOS 8:
- Swift programming language
- Metal graphics & games framework
- Extensibility: apps can now share information between each other
- Widgets in notification center
1-on-1 meetings available with Al from Networth to discuss benefits and claims; from after the lunch-&-learn, 13:30 onwards.
Nina Mehta, a designer at Pivotal Labs, discusses strategies to get design work prioritized amongst other product priorities.
Angry Kittens with battle axes
Team Angry Kittens (Christopher Larsen, Maya Kenedy, Alex Christodoulou, Ernst Riemer) do battle at the Paypal BattleHack and head up first place with their iBeacon-based child locator app, Security Blanket. The prize: a full-scale battle axe.
They will be flying out to the World Paypal BattleHack finals in November in San Jose, California.
In the fourth “Is TDD Dead?” debate, DHH, Martin Fowler, and Kent Beck discuss the cost of tests. DHH points out that well written tests don’t have to change when you’re refactoring – but he finds that he spends far more time changing behavior, not refactoring code, which, of course, necessitates changes to the tests. He states:
“I want the system to do something else than what it’s currently doing. Sometimes that’s adding new behavior, but a lot of the time that’s also changing existing behavior. If I have to change four lines of test code for every line of production code, then there’s something not right there.”
DHH makes a great point. We all have to consider the cost of change. Lots of things could change in a system: the behaviors specified by the product owner, the database technologies dicatated by your IT departments, the user interfaces needed by your users, even the frameworks written by folks like DHH.
Let’s take the example DHH tossed out in the discussion: a change to an ActiveRecord data validation (e.g.,
validates :some_field, presence: true). He says that he sees people write a unit test for that declarative data validation, followed by a functional test, followed by a system test. So, what will it take to change that data validation?
If you’ve really written three different tests, at three different levels of the system, for that data validation, then all three of those tests will have to change – along with the validation declaration itself.
This is rigidity. Several things in your system have to stay in sync. Why? Because they all know the same secret: that
:some_field is required.
When you change a behavior in your system, how many tests should have to change? One. Do you really need to test the same behavior again and again? No. In fact, in doing so, you’ve spread knowledge of that behavior around your system.
In the real world, we want to spread knowledge as far and wide as possible. As more people know and understand our world, we increase our power to change the world, and to understand the consequences of that change.
A software system is not like our world. Our ability to change a software system is inversely proportional to the spread of knowledge within that system. Like evil dictators, our power over our software system depends on the ignorance of the objects within that system.
Do the right thing. Be evil.
I want to go fast forever.
Let me back up. My client wants a new feature for their software. I’ve been doing this long enough to know that there’s a good chance they’ll want to change what they see, once they see it. So I want to show them something as quickly as possible – before I waste time building the wrong thing.
But sometimes I can’t show them something quickly.
Sometimes the code is just plain indecipherable. It takes me a long time to understand it, because the writer did not think about someone ever reading it. And that slows me down.
Sometimes it’s downright tedious. Sometimes lots of parts of the system have to stay in sync, because they all know something – and when that “something” changes, they all have to change with it. And that slows me down.
Sometimes it’s frustrating. When I make one change, ten other things break, for reasons I don’t understand. This slows me down. I have to build a vast mental model of the software in order to keep track of everything. That takes a long time, and it’s exhausting. And that slows me down.
I want to go fast forever.
But I can’t. I can’t because my code isn’t clean. I need to clean it.
How do I keep code clean? I change it. Every new feature of the system changes my understanding of the system, and of the problem domain. And my code needs to reflect that. I need to make the code the clearest, cleanest, simplest, and most obvious expression of the problem domain as I currently understand it. Every time I add new behaviors to the system, I need to update the code, refactor it. Every time.
But fear keeps me from changing it. What will I break when I change this code? When I don’t change my code, it rots. And I go slower, and slower, and slower.
I lack confidence. How can I feel confident that my changes haven’t broken any of the expected behaviors of the system? I need a magic button that I can press at any time that will instantly tell me if I’ve broken something.
I haven’t found a magic button. So what do I do instead? I write tests. And those tests, if written well, will quickly tell me if I’ve broken something. Depending on how I write them, they might also tell me other things about the design of the system. But that’s a different story.
Tests are an implementation detail for a feature of your team: the ability to go fast forever. They don’t come for free. They’re hard work. They’re not an end unto themselves. They’re a means to an end. There are other ways to implement this same feature. But from what I’ve seen, they’re more expensive, slower, and less reliable. If I find a cheaper way to implement this feature, I’ll gladly try it. I still want that magic button. Till then.
Redis is an advanced key-value store or a data structure server. This presentation will cover the following topics:
- An overview of Redis
- Data Structures
- Basics of Setup and Installation
- Basics of Administration
- Programming with Redis
- Considerations of Running Redis in a Virtual Machine
- Redis Resources
There will be a number of demonstrations to help explain some of the concepts being presented.
Faisal Akber has been working in the Information Technology industry for over seventeen (17) years. He has developed software on a number of platforms ranging from tiny Embedded systems to large IBM Mainframes. Faisal currently is on the Data Management team within VMware Global Support Services and has worked at VMware for over nine (9) years. In the Data Management team, he helps internal and external customers on a number of database platforms including Redis, VMware Postgres, Hadoop and others. In his spare time, he enjoys his hobbies as a maker and Amateur Radio operator. His call-sign is VA3SFA.
In this session we will explore using Spring Data, Spring Boot and Pivotal GemFire to build lightweight and scalable applications that use an in memory distributed grid (IMDG) as their data source.
We will cover the basics of Pivotal’s IMDG and how Spring Data and Boot can be used to rapidly develop powerful and horizontally scalable applications with it. In the process we will also go over some tips and tricks for annotation driven development and testing against IMDG.
Spring Boot, the new convention-over-configuration centric framework from the Spring team at Pivotal, marries Spring’s flexibility with conventional, common sense defaults to make application development not just fly, but pleasant! Join Spring developer advocate Josh Long@starbuxman for a look at what Spring Boot is, why it’s turning heads, why you should consider it for your next application (REST,web, batch, big-data, integration, whatever!) and how to get started.
Josh Long (http://twitter.com/starbuxman) is the Spring developer advocate for the Spring team at Pivotal (http://spring.io/team/jlong). Josh is the lead author on Apress’ Spring Recipes, 2nd Edition, and a SpringSource committer and contributor. When he’s not hacking on code, he can be found at the local Java User Group or at the local coffee shop. Josh likes solutions that push the boundaries of the technologies that enable them. His interests include scalability, BPM, grid processing, mobile computing and so-called “smart” systems. He blogs at blog.springsource.org or joshlong.com.
Spring 4 ships with Java 8 support – that means you can start using all the great features of Java 8 right away. This presentation will show examples of how to use Java 8 with Spring 4 in the repository layer, the services layer and the controller layer. For each example we will show a Java 7 and a Java 8 version so that you can easily see the pros and cons of the Java 8 based solution. No previous experience with Java 8 is required or assumed, we will cover some basic features of Java 8 as we go along.
About our speaker:
Adib is an expert programmer and has a passion for the interface between business and technology. He launched his career as a coder with a number of entrepreneurial organizations, ranging from small startups to (the then 750-employee) RIM. Adib has trained and mentored thousands of developers at organizations throughout Canada, USA and Europe. His substantial technical knowledge, extensive project experience and ability to look at technical problems from a variety of perspectives allow him to create innovative solutions to ‘real world’ problems.
Mike Grafton talks about the Android unit-testing framework Robolectric in this talk titled “Everything you always wanted to know about Robolectric (but were afraid to ask)”.
a.k.a. The World’s Smallest PaaS
In this blog post, we describe deploying Cloud Foundry/Elastic Runtime to our VMware/vCenter setup (i.e. the world’s smallest IaaS) in order to create the World’s Smallest PaaS (Platform as a Service).
[2014-10-18 this blog post has been updated to reflect ESXi 5.5U2, VCSA 5.5U2, the pivotal.io domain, and Pivotal CF 1.3.1]
[2014-06-29 this blog post has been updated to reflect installation on a 64GiB Mac Pro (not a 16GiB Mac Mini  ) with 48GiB allocated to the ESXi VM]
Previous blog posts have covered setting up the necessary environment:
- World’s Smallest IaaS, Part 1 describes installing VMware ESXi and VMware vCenter on an Apple Mac Pro
- World’s Smallest IaaS, Part 2 describes installing Cloud Foundry’s Ops Manager and deploying BOSH to the ESXi/vCenter
Uploading and Adding Elastic Runtime
- Browse to our Ops Manager: https://opsmgr.cf.nono.com/. You may need to re-authenticate (account: pivotalcf, password is whatever we set the password to when we deployed Ops Manager in Part 2)
- Click on Import a Product (see image)
- Browse to the directory that contains the files that we untarred from the 5.6GB file we downloaded from network.pivotal.io in Part 2 (the directory name should be pcf-126.96.36.199_allinone)
- select the file named cf-188.8.131.52.pivotal and upload it
- When it has finished uploading, we see green band at the top of the screen confirming that we’ve “Successfully added product“.
- We see a new option in the left hand navbar: Pivotal Elastic Runtime. Hover our mouse over that option to make the blue Add button appear. Click the blue Add button.
Configuring Elastic Runtime
- Click the Pivotal Elastic Runtime tile to begin configuration
- Click HAProxy (left navbar)
- HAProxy IPs: 10.9.8.40 (the App domain, the wildcard IP address for ‘*.cf.nono.com’)
- Click Generate Self-Signed RSA Certificate 
When it asks for domains, type *.cf.nono.com; click Generate
- Check Trust Self-Signed Certificates
- click Save
- Click the Cloud Controller tab on the left hand navbar
- System domain: cf.nono.com
- Apps domain: cf.nono.com
- Click Save
Installing Elastic Runtime
- Click < Installation Dashboard
- Click the white-on-blue button Apply Changes (on the right hand side)
- We see the install screen. We click on Show verbose output because we like watching the installation messages
Our initial install may end in failure; this is often remedied by attempting the install again.
- Click Okay
- Click the blue Apply changes button
- Click Ignore errors and start the install
This is a successful deploy:
Click Return to Installation Dashboard
As a final test of Cloud Foundry, we log into the Console, which is Cloud Foundry application that is included by default in the base Cloud Foundry installation.
- click on the Pivotal Elastic Runtime tile
- click on the Credentials tab
- browse to the UAA section; look for the Admin Credentials
- browse to the Console application
- Log in using the Admin Credentials. Yes, even though “admin” is not an email address, it will work when logging into the console.
- Pick an organization name; we chose CF Engineering
Note: we can’t send email invites because we never configured out outbound mail server. Configuring outbound email may require help from the IT department.
Congratulations, we have an up-and-running Cloud Foundry installation. Ready for more? Let’s push our first application to our Cloud Foundry installation by following the subsequent post, World’s Smallest IaaS, Part 4: Hello World.
1 We used a 64GiB Mac Pro because we were unable to install on the 16GiB Mac Mini. We tried to install of Elastic Runtime on the Mac Mini, but the install came to a screeching halt:
Error 100: No available resources Task 20 error For a more detailed error report, run: bosh task 20 --debug Try no. 4 failed. Exited with 1.
2 For those curious about installing with a genuine SSL cert, install this Certificate PEM, this Private Key PEM. Only use this certificate and key if your System and App domains are cf.nono.com and your HA Proxy IP is 10.9.8.40. Note: be sure to check Trust Self-Signed Certificates. Really. Otherwise the install will fail.
3 CPU core over-subscription is not something we worry about. vSphere 5.5’s Virtual CPU limit is 32 Virtual CPUs per core, which means that our 4-core Mac Pro could support as many as 128 Virtual CPUs. Cloud Foundry’s Engineering Team’s servers are often over-subscribed by a factor of more than 20:1 (i.e. as many as 240 cores allocated, but only 12 physical cores available).
# Gemfile group :test do gem 'elasticsearch-extensions' end
# spec_helper.rb # Add after other requires. Rake needs to be loaded. require 'rake' require 'elasticsearch/extensions/test/cluster/tasks' RSpec.configure do |config| # Snipped other config. config.before :each, elasticsearch: true do Elasticsearch::Extensions::Test::Cluster.start(port: 9200) unless Elasticsearch::Extensions::Test::Cluster.running? end config.after :suite do Elasticsearch::Extensions::Test::Cluster.stop(port: 9200) if Elasticsearch::Extensions::Test::Cluster.running? end end
class User < ActiveRecord::Base include Elasticsearch::Model include Elasticsearch::Model::Callbacks index_name [Rails.env, model_name.collection.gsub(/\//, '-')].join('_') end
describe 'Searching for a user', elasticsearch: true do before do # Create and destroy Elasticsearch indexes # between tests to eliminate test pollution User.__elasticsearch__.create_index! index: User.index_name # There are two options for how you create your objects # 1. Create your objects here and they should be synchronised # through the Elasticsearch::Model callbacks User.create! # 2. Call import on the model which should reindex # anything you've "let!" User.import # Sleeping here to allow Elasticsearch test cluster # to index the objects we created sleep 1 end after do User.__elasticsearch__.client.indices.delete index: User.index_name end end