2. Flying Crazyflie via JavaScript
I built Crazyflie 2 years ago, but haven't really played with it so I tried to fly it with Cyclon.js, had errors with connection so tried with Aerogel but ran into the same problem :(
Next time!

3. Controlled Arduino with JavaScript using Johnny Five

Johnny Five is a JavaScript Robotics and IoT programming framework.
Got Arduino blinking its LED via JavaScript!

Used Node-RED to set the color of the LightBlue Bean’s LED based on the sentiment of a Twitter feed.

OK... so grabbing some small Twitter stream was hard to tell if anything is happening so grabbed all of tweets and the sentiments of the Twittersphere was going nuts with "great", "neutral" and "awful" :)

Used Node-RED to send an email whenever the temperature drops below or exceeds a threshold. Node-RED connects to the LightBlue Bean once a minute, requests the temperature and sends an email if the temperature is outside the set interval. Install Node.js, install Node-RED and run it.

I think it's running but my room temperature is too stable... maybe I need to put the Bean in refrigerator? ;P

Controlling LightBlue Bean from Android:Installed BeanLoader Android app. In the app, there are lots of sample apps. For example:AccelerationLED > Changing LED color based on accelerometerBeanBlink > Changing LED color rotating among red, green and blueBasically you select the sketch, verify the sketch and upload it to the Bean. You can also export the code to editor to read and edit the sketch.

Pin layout:

System view:

I need to think about what to create with this :D

Disclaimer: The opinions expressed here are my own, and do not reflect those of my employer. -Fumi Yamazaki

2015年7月8日水曜日

1 Start with needs: Service design starts with identifying user needs, not government needs2 Do less: Government should only do what only government can do. If we’ve found a way of doing something that works, we should make it reusable and shareable instead of reinventing the wheel every time.3 Design with data: In most cases, we can learn from real world behaviour by looking at how existing services are used. Let data drive decision-making, not hunches or guesswork.4 Do the hard work to make it simple: Making something look simple is easy. Making something simple to use is much harder — especially when the underlying systems are complex — but that’s what we should be doing. Don’t take “It’s always been that way” for an answer.5 Iterate. Then iterate again: The best way to build good services is to start small and iterate wildly. Release Minimum Viable Products early, test them with actual users, move from Alpha to Beta to Live adding features, deleting things that don’t work and making refinements based on feedback.

6 This is for everyone: Accessible design is good design. Everything we build should be as inclusive, legible and readable as possible. We’re designing for the whole country, not just the ones who are used to using the web.

7 Understand context: We’re not designing for a screen, we’re designing for people. We need to think hard about the context in which they’re using our services. Are they in a library? Are they on a phone? Are they only really familiar with Facebook? Have they never used the web before?

8 Build digital services, not websites: A service is something that helps people to do something. Our job is to uncover user needs, and build the service that meets those needs.

9 Be consistent, not uniform: We should use the same language and the same design patterns wherever possible. This helps people get familiar with our services, but when this isn’t possible we should make sure our approach is consistent. [List of design patterns]

10 Make things open: it makes things better: We should share what we’re doing whenever we can. With colleagues, with users, with the world. Share code, share designs, share ideas, share intentions, share failures. The more eyes there are on a service the better it gets — howlers are spotted, better alternatives are pointed out, the bar is raised.

1. Understand what people need: We must begin digital projects by exploring and pinpointing the needs of the people who will use the service, and the ways the service will fit into their lives. Whether the users are members of the public or government employees, policy makers must include real people in their design process from the beginning. The needs of people — not constraints of government structures or silos — should inform technical and design decisions. We need to continually test the products we build with real people to keep us honest about what is important.2. Address the whole experience, from start to finish: We need to understand the different ways people will interact with our services, including the actions they take online, through a mobile application, on a phone, or in person. Every encounter — whether it's online or offline — should move the user closer towards their goal.3. Make it simple and intuitive: Using a government service shouldn’t be stressful, confusing, or daunting. It’s our job to build services that are simple and intuitive enough that users succeed the first time, unaided.4. Build the service using agile and iterative practices: We should use an incremental, fast-paced style of software development to reduce the risk of failure. We want to get working software into users’ hands as early as possible to give the design and development team opportunities to adjust based on user feedback about the service. A critical capability is being able to automatically test and deploy the service so that new features can be added often and be put into production easily.5. Structure budgets and contracts to support delivery: To improve our chances of success when contracting out development work, we need to work with experienced budgeting and contracting officers. In cases where we use third parties to help build a service, a well-defined contract can facilitate good development practices like conducting a research and prototyping phase, refining product requirements as the service is built, evaluating open source alternatives, ensuring frequent delivery milestones, and allowing the flexibility to purchase cloud computing resources. Ref. TechFAR Handbook (FAR=Federal Acquisition Regulation)6. Assign one leader and hold that person accountable: There must be a single product owner who has the authority and responsibility to assign tasks and work elements; make business, product, and technical decisions; and be accountable for the success or failure of the overall service. This product owner is ultimately responsible for how well the service meets needs of its users, which is how a service should be evaluated. The product owner is responsible for ensuring that features are built and managing the feature and bug backlogs.7. Bring in experienced teams: We need talented people working in government who have experience creating modern digital services. This includes bringing in seasoned product managers, engineers, and designers. When outside help is needed, our teams should work with contracting officers who understand how to evaluate third-party technical competency so our teams can be paired with contractors who are good at both building and delivering effective digital services. The makeup and experience requirements of the team will vary depending on the scope of the project.8. Choose a modern technology stack: The technology decisions we make need to enable development teams to work efficiently and enable services to scale easily and cost-effectively. Our choices for hosting infrastructure, databases, software frameworks, programming languages and the rest of the technology stack should seek to avoid vendor lock-in and match what successful modern consumer and enterprise software companies would choose today. In particular, digital services teams should consider using open source, cloud-based, and commodity solutions across the technology stack, because of their widespread adoption and support by successful consumer and enterprise technology companies in the private sector.9. Deploy in a flexible hosting environment: Our services should be deployed on flexible infrastructure, where resources can be provisioned in real-time to meet spikes traffic and user demand. Our digital services are crippled when we host them in data centers that market themselves as “cloud hosting” but require us to manage and maintain hardware directly. This outdated practice wastes time, weakens our disaster recovery plans, and results in significantly higher costs.10. Automate testing and deployments: Today, developers write automated scripts that can verify thousands of scenarios in minutes and then deploy updated code into production environments multiple times a day. They use automated performance tests which simulate surges in traffic to identify performance bottlenecks. While manual tests and quality assurance are still necessary, automated tests provide consistent and reliable protection against unintentional regressions, and make it possible for developers to confidently release frequent updates to the service.11. Manage security and privacy through reusable processes: Our digital services have to protect sensitive information and keep systems secure. This is typically a process of continuous review and improvement which should be built into the development and maintenance of the service. At the start of designing a new service or feature, the team lead should engage the appropriate privacy, security, and legal officer(s) to discuss the type of information collected, how it should be secured, how long it is kept, and how it may be used and shared. The sustained engagement of a privacy specialist helps ensure that personal data is properly managed. In addition, a key process to building a secure service is comprehensively testing and certifying the components in each layer of the technology stack for security vulnerabilities, and then to re-use these same pre-certified components for multiple services.12. Use data to drive decisions: At every stage of a project, we should measure how well our service is working for our users. This includes measuring how well a system performs and how people are interacting with it in real-time. Our teams and agency leadership should carefully watch these metrics to find issues and identify which bug fixes and improvements should be prioritized. Along with monitoring tools, a feedback mechanism should be in place for people to report issues directly.13. Default to open: When we collaborate in the open and publish our data publicly, we can improve Government together. By building services more openly and publishing open data, we simplify the public’s access to government services and information, allow the public to contribute easily, and enable reuse by entrepreneurs, nonprofits, other agencies, and the public.

Strategy Objectives: The Digital Government Strategy sets out to accomplish three things:

- Enable the American people and an increasingly mobile workforce to access high-quality digital government information and services anywhere, anytime, on any device. Operationalizing an information-centric model, we can architect our systems for interoperability and openness, modernize our content publication model, and deliver better, device-agnostic digital services at a lower cost.

- Ensure that as the government adjusts to this new digital world, we seize the opportunity to procure and manage devices, applications, and data in smart, secure and affordable ways. Learning from the previous transition of moving information and services online, we now have an opportunity to break free from the inefficient, costly, and fragmented practices of the past, build a sound governance structure for digital services, and do mobile “right” from the beginning.

- Unlock the power of government data to spur innovation across our Nation and improve the quality of services for the American people.
We must enable the public, entrepreneurs, and our own government programs to better leverage the rich wealth of federal data to pour into applications and services by ensuring that data is open and machine-readable by default.

Strategy Principles:

- An “Information-Centric” approach – Moves us from managing “documents” to managing discrete pieces of open data and content17 which can be tagged, shared, secured, mashed up and presented in the way that is most useful for the consumer of that information.

1. Make Open Data, Content, and Web APIs the New Default
2. Make Existing High-Value Data and Content Available through Web APIs

- A “Shared Platform” approach – Helps us work together, both within and across agencies, to reduce costs, streamline development, apply consistent standards, and ensure consistency in how we create and deliver information.

- A “Customer-Centric” approach – Influences how we create, manage, and present data through websites, mobile applications, raw data sets, and other modes of delivery, and allows customers to shape, share and consume information, whenever and however they want it.

The Digital Government Strategy requires each agency to establish specific, measurable goals for delivering better services at a lower cost through their governance structure(s). Agencies should establish goals that are tailored to their organization’s needs, and consider pursuing the following types of goals:

Guideline 3: Cross-Agency Collaboration and Shared Services and Tools Leverage existing infrastructure, shared tools, best practices, and communities of practice, and coordinate within and across agencies to create efficiency and reduce duplication

Guideline 4: Technical Considerations Use the most recent and up-to-date technical standards to deliver a better customer experience

- Avoid being passive, whenever possible.
- Acronyms can confuse readers. Whenever possible, use the full name.
- Address the user as you wherever possible.
- Avoid duplication. Check that the user need you’re trying to address has not already been covered.
- Be concise.
- Conscious Style Guide: Gender neutrality, etc.
- Plain language: Don’t use formal or long words when easy or short ones will do.
- Follow a consistent capitalization scheme.
- Present legal and technical content in plain language.
- Punctuation: Capitalize the first word of every bullet. Include a period at the end of the bullet only if that point is a complete sentence.
- Optimize headings and titles
- Avoid FAQs: If you write content by starting with user needs, you won’t need to use FAQs.
- Specific words and phrases

2015年7月7日火曜日

Google Votes is an experiment in liquid democracy built on Google's internal corporate Google+ social network. A Liquid Democracy system gives all the control of Direct Democracy with the scalability of Representative Democracy. Users can vote directly or delegate power through their social networks.

Before we jump in to Google Votes, following video "Liquid Democracy In Simple Terms" might be a good start:

Fortunately the team was successful in making those techtalk videos and paper public, I hope you enjoy. Note, some of the links in the video will not work since it is limited access within Google's corporate network.

Techtalk video: Voting Methods with Google Votes
This talk covers Approval, Ranked, Range/Score, and Plurality voting along with the Borda and Schulze ranking algorithms and their relation to Condorcet's Paradox.

Techtalk video: Liquid Democracy with Google Votes

This talk covers user experience aspects of delegated voting and three graph algorithms for flowing votes through a social graph called Tally, Coverage, and Power.

Other readings on Liquid Democracy, social network voting, e-governance, and social choice

2015年7月4日土曜日

This year at Maker Faire Bay Area, I participated as one of the volunteer staffs to demo Google Cardboard. I couldn't shoot a photo of myself, but my colleague Hakuro did and tweeted it out- thanks Hakuro-san :D

Google was one of the sponsors for Maker Faire Bay Area this year, and we had a tent to showcase some of our products like Cardboard, Project Loon, Project Wing, and some of the personal maker projects that employees were working on.

You can see the video of Chris walking through the exhibits here:

We also had the Maker Breaker Lab, where kids can select what they want to break (video tapes, computer keyboards, porcelain, etc...) and you can actually watch how it breaks.

"Learn to solder" tent was also sponsored by Google, where everyone can solder their LED badge.

Disclaimer: The opinions expressed here are my own, and do not reflect those of my employer. -Fumi Yamazaki