the evolving ultrasaurus https://www.ultrasaurus.com Sarah Allen's reflections on internet software and other topics Wed, 17 Jan 2018 12:53:26 +0000 en-US hourly 1 https://wordpress.org/?v=4.9.2 non-violent resistance and bright-eyed wisdom #mlk https://www.ultrasaurus.com/2018/01/non-violent-resistance-and-bright-eyed-wisdom-mlk/ https://www.ultrasaurus.com/2018/01/non-violent-resistance-and-bright-eyed-wisdom-mlk/#respond Mon, 15 Jan 2018 20:52:23 +0000 https://www.ultrasaurus.com/?p=6435 Continue reading ]]> When Dr. Martin Luther King, Jr. accepted the Nobel Peace Prize in Oslo, Norway, December 11, 1964, his speech was an inspiring call to “make brotherhood, freedom, and justice realities in the United States of America.” The speech could have been written about the United States of America today.

While celebrating and honoring the high and joyous moment of receiving the award, he also provides a rare assessment of how this work profoundly affects the individuals who take action — the “devotees of nonviolence who have moved so courageously against the ramparts of racial injustice and who in the process have acquired a new estimate of their own human worth.”

The following direct quote from the speech entitled The Quest for Peace and Justice provides a simple guide to non-violent resistance.

The nonviolent resisters can summarize their message in the following simple terms:

  • We will take direct action against injustice despite the failure of governmental and other official agencies to act first.
  • We will not obey unjust laws or submit to unjust practices.
  • We will do this peacefully, openly, cheerfully because our aim is to persuade.
  • We adopt the means of nonviolence because our end is a community at peace with itself.
  • We will try to persuade with our words, but if our words fail, we will try to persuade with our acts.
  • We will always be willing to talk and seek fair compromise, but we are ready to suffer when necessary and even risk our lives to become witnesses to truth as we see it.

I’ve highlighted a few parts of the speech below that feel particularly relevant today, where our complex technology is simultaneously empowering and disempowering.

Modern man has brought this whole world to an awe-inspiring threshold of the future. He has reached new and astonishing peaks of scientific success. He has produced machines that think and instruments that peer into the unfathomable ranges of interstellar space…

Yet, in spite of these spectacular strides in science and technology, and still unlimited ones to come, something basic is missing…

Our problem today is that we have allowed the internal to become lost in the external. We have allowed the means by which we live to outdistance the ends for which we live…

We must still face prodigious hilltops of opposition and gigantic mountains of resistance. But with patient and firm determination we will press on until every valley of despair is exalted to new peaks of hope, until every mountain of pride and irrationality is made low by the leveling process of humility and compassion; until the rough places of injustice are transformed into a smooth plane of equality of opportunity; and until the crooked places of prejudice are transformed by the straightening process of bright-eyed wisdom.

Every day corporations accidentally or intentionally use machine learning and automated processes that operate at scale in ways that cause direct harm or incite violence. And in much more subtle ways, we participate in systems that oppress. The civil rights movement succeeded in changing laws, and now we face the challenge of changing our society.

 

via @TheKingCenter: “thread of #MLK speeches and sermons in which he speaks truth to power, shares about his philosophy of nonviolence and expounds on issues of injustice and what our righteous, rigorous response should be. Relevant. Revelatory. Revolutionary.”

]]>
https://www.ultrasaurus.com/2018/01/non-violent-resistance-and-bright-eyed-wisdom-mlk/feed/ 0
more little rules for working life https://www.ultrasaurus.com/2018/01/more-little-rules-for-working-life/ https://www.ultrasaurus.com/2018/01/more-little-rules-for-working-life/#respond Sun, 14 Jan 2018 19:35:38 +0000 https://www.ultrasaurus.com/?p=6124 Continue reading ]]> It helps me to create little rules that provide default decisions for common and unusual situations. A couple of years ago, I wrote down my little rules for working life. Since then, I’ve collected a few more…

Communication

  • Speak the unspoken.
  • Have difficult conversations.
  • Find something remarkable, and remark on it, every day.
  • Not everything needs to be said.

Decision-Making

  • Be intentional: for me, it takes reflection and constant conscious effort for my words and actions to reflect my values.
  • Consider your influencers (the people who influence you), and choose them as intentionally as you can.
  • Have a plan. Learn something. Change the plan.
  • Play the long game. Sometimes we have to do stuff that we don’t care about in the short-term, in order to meet expectations from people who decide if we get paid or if we get privileges. Even while we do the stupid short-term things, we can sometimes set ourselves up for some potentially awesome, or at least potentially meaningful future.
  • Focus on the outcome. Imagine what happens after you reach your goal. Then what? Often the real goal is the next thing, or the thing after that.

Getting Unstuck

  • When you hit a wall, step back and learn. Learn more about the problem. Who else sees it as a problem? Who made this wall anyhow? It’s probably there for a reason and the problem might be an unintended consequence.
  • Get to know the people. The system is made of people, and usually those aren’t the same people who made the system.
  • Write stuff down. Sometimes what you think you heard wasn’t the same thing other people heard.
  • Wait a week and ask again. Or a month. Or just listen for the moment when someone else raises the same problem, and chime in.

“Curiosity is the most under utilized tool of leaders” — Amy Edmondson
“Don’t fight stupid, make more awesome” — Jesse Robbins
“Make new mistakes.” — Esther Dyson, 2008 post

]]>
https://www.ultrasaurus.com/2018/01/more-little-rules-for-working-life/feed/ 0
event-driven architectural patterns https://www.ultrasaurus.com/2017/12/event-driven-architectural-patterns/ https://www.ultrasaurus.com/2017/12/event-driven-architectural-patterns/#respond Sun, 31 Dec 2017 00:50:03 +0000 https://www.ultrasaurus.com/?p=6255 Continue reading ]]> Martin Fowler’s talk “The Many Meanings of Event-Driven Architecture” at GOTO2017 provides a good overview of different patterns that all are described as “event-driven” systems. At the end of the talk, he references to an earlier event-driven article, which offers a good prose description of these different patterns that folks are calling event-driven programming. In this talk, he covers specific examples that illustrate the patterns, grounding them in specific applications.

Event Notification

Person -> CRM -> Insurance Quoting -> CommunicationsFor example: address changed

Scenario: CRM system stores information about people. An insurance quoting system generates insurance rates based on demographics and address. When someone’s address changes, we need to calculate a new value for the cost of insurance.

We often don’t want these systems to be coupled, instead we want a reversal of dependencies. This patterns is used in relatively large scale systems, and also a long-established client-side pattern to separate GUIs and the rest of your code.

The change becomes a first class notion. We bundle the notification + data about the change.

Events OR Commands
* Commands enforce the coupling, it’s very different from an event, it conveys intent
* Naming makes all the diffrence

Additional property → easy to add systems without modifying the original system

Martin notes “the dark side of event notification” where your system quickly becomes hard to reason about because there is not statement of overall behavior.

Event-Carried State Transfer

Named in contrast to REST (Representational State Transfer), the event carries ALL of the data needed about the event, which completely de-couples the target system from the system that originates the event.

Of course, this introduces data replication and eventual consistency (which can be good for some use cases); however, this is a less common pattern since this lack of consistency can actually make the system more complex.

Event Sourcing

This is one of my favorite patterns which Martin explains nicely in the talk with two examples:

  • Version control is an event source system for code.
  • Accounting ledgers track every credit or debit, which are the source records (events), and the balance is calculated from those records.

Benefits

  • auditing: natural part of the system
  • debugging: easy to replay a subset of events locally
  • historic state: time travel!
  • alternative state: branching, correcting errors
  • memory image: application state can be volatile (since persistence is achieved with event log, processing can happen quickly in memory based on recent events that can quickly regenerate state based on recent snapshots)

Drawbacks

  • unfamiliar
  • external systems: everything needs to be an event
  • event schema: what happens when your data types change?
  • identifiers: how to create identifiers to reliably replay events

Common (Related) Challenges

  • **asynchronous processing** can be hard to reason about. This isn’t required for an event sourcing system, yet it is easy to add and needed in most server-side systems. Useful to remember that this is distinct from the core event sourcing pattern.
  • **versioning** is another option that is quite useful, yet also adds complexity. Greg Young’s advice: don’t have any business logic between the event and the internal representation of a record.

Martin talks about the difference between input event (the intention) and the output event (the effect). In deciding what to store think about how we would fix a bug. The key thing is to be clear about what you are storing, and probably most of the time you want to store both.

CQRS

Coined by Greg Young, Command Query Responsibility Segregation, is where your write model is different from your read model. Two software components: one for updating the current model (the command component), and one for reading the state (the query component).

Martin suggests that we need to be wary of this approach. A good pattern when used appropriately (which you could say of any model). But isn’t Event Sourcing just a special case of this? Maybe the special case is what provides a structure that make it easier to reason about.

]]>
https://www.ultrasaurus.com/2017/12/event-driven-architectural-patterns/feed/ 0
exploring ghostscript API in C https://www.ultrasaurus.com/2017/11/getting-started-with-ghostscript-api-in-c/ https://www.ultrasaurus.com/2017/11/getting-started-with-ghostscript-api-in-c/#respond Fri, 24 Nov 2017 14:56:21 +0000 https://www.ultrasaurus.com/?p=6359 Continue reading ]]> Ghostscript lets you do all sorts of PDF and PostScript transformations. It’s got a command-line tool which is great for page-level operations.

Installation on a mac is pretty easy with homebrew:

brew install ghostscript

The syntax for the commands not very memorable, but easy once you know it. To get a PNG from a PDF:

gs -sDEVICE=pngalpha -o output.png input.pdf

We can also use the API to call the engine from C code. Note: to use this from a program we need to publish our source code (or purchase a license from the nice folks who create and maintain Ghostscript), which seems fair to me. See license details.

To do the exact same thing as above, I created a small program based on the example in the API doc, which I’ve posted on github.

What I really want to do is to replace text in a PDF (using one PDF as a template to create another). It seems like all the code I need is available in the Ghostscript library, but maybe not exposed in usable form:

  • Projects Seeking Developers Driver Architecture was the only place in the docs that I learned that we can’t add a driver without modifying the source code: “Currently, drivers must be linked into the executable.” Might be nice for these to be filed as bugs so interested developers might discuss options here. Of course, not sure that making a driver is a good solution to my problem at all.
  • There’s an option -dFILTERTEXT that removes all text from a PDF that I thought might provide a clue. I found the implementation in gdevoflt.c with a comment that it was derived from gdevflp.c.
  • gdevflp: This device is the first ‘subclassing’ device; the intention of subclassing is to allow us to develop a ‘chain’ or ‘pipeline’ of devices, each of which can process some aspect of the graphics methods before passing them on to the next device in the chain.

So, this appears to require diving into the inner-workings of Ghostscript, yet the code seems to be structured so that it is easily modifiable for exactly this kind of thing. It seems like it would be possible to add a filter that modifies text, rather than just deleting it, as long as the layout is unaffected. This implies setting up for building and debugging GhostScript from source and the potential investment of staying current with the codebase, which might not work for my very intermittent attention.

]]>
https://www.ultrasaurus.com/2017/11/getting-started-with-ghostscript-api-in-c/feed/ 0
getting started with docker https://www.ultrasaurus.com/2017/10/getting-started-with-docker/ https://www.ultrasaurus.com/2017/10/getting-started-with-docker/#respond Mon, 09 Oct 2017 14:17:24 +0000 https://www.ultrasaurus.com/?p=6328 Continue reading ]]> Learning about docker this weekend… it always is hard to find resources for people who understand the concepts of VMs and containers and need to dive into something just a little bit complicated. I had been through lots of intro tutorials, when docker first arrived on the scene, and was seeking to set up a hosted dev instance for existing open source project which already had a docker set up.

Here’s an outline of the key concepts:

  • docker-machine: commands to create and manage VMs, whether locally or on a remote server
  • docker: commands to talk to your active VM that is already set up with docker-machine
  • docker-compose: a way to create and manage multiple containers on a docker-machine

As happens, I see parallels between human spoken language and new technical terms, which makes sense since these are things made by and for humans. The folks who made Docker invented a kind of language for us to talk to their software.

I felt like I was learning to read in a new language, like pig-latin, where words have a prefix of docker, like some kind of honorific

They use docker- to speak to VMs locally or remotely, and docker (without a dash) is an intimate form of communication with your active VM

Writing notes here, so I remember when I pick this up again. If there are Docker experts reading this, I’d be interested to know if I got this right and if there are other patterns or naming conventions that might help fast-track my learning of this new dialect for deploying apps in this land of containers and virtual machines.

Also, if a kind and generous soul wants to help an open source project, I’ve written up my work-in-progress steps for setting up OpenOpps-platform dev instance and would appreciate any advice, and of course, would welcome a pull request.

]]>
https://www.ultrasaurus.com/2017/10/getting-started-with-docker/feed/ 0
ultimate serverless combo: Firestore + Functions https://www.ultrasaurus.com/2017/10/ultimate-serverless-combo-firestore-functions/ https://www.ultrasaurus.com/2017/10/ultimate-serverless-combo-firestore-functions/#respond Tue, 03 Oct 2017 17:07:27 +0000 https://www.ultrasaurus.com/?p=6318 Continue reading ]]> Serverless development just got easier — today’s release of Cloud Firestore with event triggers for Cloud Functions combine to offer significant developer velocity from idea to production to scale.

I’ve worked on dozens of mobile and web apps and have always been dismayed by the amount of boilerplate code needed to shuffle data between client and server and implement small amounts of logic on the server-side. Serverless APIs + serverless compute reduce the amount of code needed to write an app, increasing velocity throughout the development cycle. Less code means fewer bugs.

Cloud Firestore + Cloud Functions with direct-from-mobile access enabled by Firebase Auth and Firebase Rules combine to deliver something very new in this space. Unhosted Web apps are also enabled by Web SDKs.

It is not a coincidence that I’ve worked on all of these technologies since joining Google last year. My first coding project at Google was developing the initial version of the Firestore UI in the Firebase Console. I then stepped into an engineering management role, leading the engineering teams that work on server-side code where Firebase enables access to Google Cloud.

Cloud Firestore

  • Realtime sync across Web and mobile clients: This is not just about realtime apps. Building user interfaces is substantially easier: using reactive patterns and progressively filling in details allows apps to be ready for user interaction faster.
  • Scales with the size of the result set: Simple apps are simple. For complex apps, you still need to be thoughtful about modeling your data, and the reward is that anything that works for you and your co-workers will scale to everyone on the planet using your app. From my perspective, this is the most significant and exciting property of the Cloud Firestore.
  • iOS, Android and Web SDKs

Cloud Functions

  • Events for create, write, update, and delete (learn how)
  • Write and deploy JavaScript functions that do exactly and only what you need
  • You can also use TypeScript (JS SDKs include typings)

All the Firebase things

  • Free tier and when you exceed that, you only pay for what you use.
  • Zero to planet scale: no sharding your database, no calculating how many servers you need, focus on how your app works.
  • Secure data access with Firebase Rules: simple, yet powerful declarative syntax to specify what data can be accessed by client code. For example, some data may be read-only access for social sharing or public parts of an app, user data might be only written by that user, and some other data may be only written by server-code.
  • Firebase Auth: all the social logins, email/password, phone or you can write code for custom auth
  • Lots more Firebase things

All this combines to allow developers to focus on building an app, writing new code that offers unique value. It’s been a while since I’ve been actually excited about new technology that has immediate and practical use cases. I’m so excited to be able to use this tech in the open for my side projects, and can’t wait to see the serious new apps…..

]]>
https://www.ultrasaurus.com/2017/10/ultimate-serverless-combo-firestore-functions/feed/ 0
memories of dragons https://www.ultrasaurus.com/2017/09/memories-of-dragons/ https://www.ultrasaurus.com/2017/09/memories-of-dragons/#respond Sat, 23 Sep 2017 15:52:20 +0000 https://www.ultrasaurus.com/?p=6311 In my recent trip to Krakow, I bought a little blue stuffed dragon for my niece. I became curious about the legend of the Krakow dragon and wanted to find a children’s story to listen to and maybe learn a little Polish and found a fun, modern interpretation: Smok.

Two photos: Krakow dragon statue  and child shadow that kind of looks like a dragon

]]>
https://www.ultrasaurus.com/2017/09/memories-of-dragons/feed/ 0
call it what it is https://www.ultrasaurus.com/2017/08/call-it-what-it-is/ https://www.ultrasaurus.com/2017/08/call-it-what-it-is/#respond Sun, 13 Aug 2017 22:05:44 +0000 https://www.ultrasaurus.com/?p=6302 Continue reading ]]> The news from Charlottesville is not an isolated incident. The US President responds that there is violence “on many sides.” This is false.

In Charlottesville, the police were present in riot gear, but the rioting white people were treated with kid gloves, a stark difference from Fergusen police reaction reported by @JayDowTV who was there.

These people feel comfortable declaring it a war: “And to everyone, know this: we are now at war. And we are not going to back down. There will be more events. Soon. We are going to start doing this nonstop. Across the country. I’m going to arrange them myself. Others will too, I’m sure, but I’m telling you now: I am going to start arranging my own events. We are going to go bigger than Charlottesville. We are going to go huge.”

General McMaster, US National Security Advisor tells us “I think what terrorism is, is the use of violence to incite terror and fear. And, of course, it was terrorism” (NBC via Vox)

A Christian minister writes this plainly on his post, Yes, This is Racism. We each need to declare what we stand for in this moment and always.

We are not with you, torch-bearers, in Charlottesville or anywhere.
We do not consent to this.
In fact we stand against you, alongside the very beautiful diversity that you fear.
We stand with people of every color and of all faiths, people of every orientation, nationality, and native tongue.

We are not going to have this. This is not the country we’ve built together and it will not become what you intend it to become.

So you can kiss our diverse, unified, multi-colored behinds because your racism and your terrorism will not win the day.

Believe it.

— John Pavlovitz

]]>
https://www.ultrasaurus.com/2017/08/call-it-what-it-is/feed/ 0
impact matters more than intent https://www.ultrasaurus.com/2017/08/impact-matters-more-than-intent/ https://www.ultrasaurus.com/2017/08/impact-matters-more-than-intent/#comments Mon, 07 Aug 2017 05:42:29 +0000 https://www.ultrasaurus.com/?p=6288 Continue reading ]]> Disclaimer: I work at Google. This article is based on 18 years of observing the company as an outsider, along with over a year of experience as a senior technical leader at the company.

An internal google document was published this weekend, where an individual articulated poorly reasoned arguments that demonstrated conscious bias, both about gender and about the skills necessary for software engineering. Demeaning generalizations and stereotypes were presented as unbiased fact. The author may not have intended to be disrespectful, yet caused great harm. Many women have spoken publicly about their frustration in reading this harmful rhetoric in their workplace.

For many years before I joined Google, I heard stories of sexism and racism that happened inside the company. Frankly, I know of no company which is immune to this. Companies believe they have well-established social norms around respectful behavior, good management training, effective escalation paths, etc., yet these aren’t evenly distributed. In 2006, I declared that I would not work at Google because of their hiring practices. In 2016, I decided that both Google and I had changed a bit since then. I interviewed Google even more than they interviewed me. Not including the actual day of interviews, I had 21 conversations with 17 different people before deciding to work here.

Unexpectedly, Google was the first tech company I have worked for where I didn’t routinely meet people who expressed surprise at my technical ability. There seems to be a positive bias that if you work for Google you must be technically awesome. I can’t tell whether this is universal. (I assume it isn’t. Google is a big place.) However, as evidenced by this latest rant, Google has a long way to go in creating effective social norms around discussing diversity and the efforts to make hiring and promotion fair.

We need to be careful as we address inequities. As a woman who attended private high school and studied Computer Science at a prestigious university, I have an advantage in getting a job at any tech company over a white man who joined the military to pay for college and taught himself to code. Google could, if it wanted to, hire the very best women and people of color such that it statistically matched the demographics of the United States, and not “lower the bar” yet still be homogeneous, yielding limited benefit from its diversity efforts.

Diversity and inclusion is not just about demographics. The lack of minorities and women at Google and most other tech companies is a sign that things aren’t quite right. We should look at diversity numbers as a signal, and then seek to address underlying problems around inclusion and respect. We need to include effective communication skills as part of selection criteria for new engineers and for promotion.

Ex-Google engineer Yonatan Zunger wrote a thoughtful response about how communication and collaboration are critical to the work we do. I have also written more generally about how communication is a technical skill: “We usually think of software as being made of code, but it is really made of people. We imagine what the software should do, and through our code, we turn ideas into reality…. I find it confusing that anyone could even suggest that communication is a different skill that is optional for programmers. This is what we do. We write our code in programming languages. We define things and then they exist. We make real things using language.”

I’ve worked with amazing engineers who have little else in common. The best engineers I’ve worked with solve problems differently from each other — creativity and insight combined with technical skill are the mark of a great engineer.

The Google hiring process tests for the candidate’s ability to write code and solve problems (and to some degree talk about code). This is not enough. Google and the rest of the industry needs to set a higher bar for hiring talent. It is much harder to collaborate effectively and communicate your ideas than it is to write a basic algorithm on the whiteboard.

In my experience, the ability to write great software is not tied to any outward trait, and discussion of biological or societal differences is a distraction from the core issue. We need people with a diversity of experience and perspectives to bring creative solutions to their work, and we need engineers who can work with people who are different from them with respect and enthusiasm.

I know there are good people working inside of Google to make change. I applaud the publication of research on effective teamwork. This is not enough. This work of creating change for humans is much harder than the work of writing software. Smaller companies have a greater opportunity to make change faster. We each need to step up and take a leadership role at every level of our organizations.

Impact matters more than intent.

]]>
https://www.ultrasaurus.com/2017/08/impact-matters-more-than-intent/feed/ 5
customer-driven development https://www.ultrasaurus.com/2017/06/customer-driven-development/ https://www.ultrasaurus.com/2017/06/customer-driven-development/#respond Mon, 19 Jun 2017 13:08:36 +0000 https://www.ultrasaurus.com/?p=6276 Continue reading ]]> Sometimes when I talk about customer use cases for software that I’m building, it confuses the people I work with. What does that have to do with engineering? Is my product manager out on leave and I’m standing in?

I’ve found that customer stories connect engineers to the problems we’re solving. When we’re designing a system, we ask ourselves “what if” questions all the time. We need to explore the bounds of the solutions we’re creating, understanding the edge cases. We consider the performance characteristics, scalability requirements and all sorts of other important technical details. Through all this we imagine how the system will interact. It is easier when the software has a human interface, when it interacts with regular people. It is harder, but just as important, when we write software that only interacts with other software systems.

Sometimes the software that we are building can seem quite unrelated from the human world, but it isn’t at all. We then need to understand the bigger system we’re building. At some point, the software has a real-world impact, and we need to understand that, or we can miss creating the positive effects we intend.

On many teams over many years, I’ve had the opportunity to work with other engineers who get this. When it works there’s a rhythm to it, a heartbeat that I stop hearing consciously because it is always there. We talk to customers early and often. We learn about their problems, the other technologies they use, and what is the stuff they understand that we don’t. We start describing our ideas for solutions in their own words. This is not marketing. This influences what we invent. Understanding how to communicate about the thing we’re building changes what we build. We imagine this code we will write, that calls some other code, which causes other software to do a thing, and through all of the systems and layers there is some macro effect, which is important and time critical. Our software may have the capability of doing a thousand things, but we choose the scenarios for performance testing, we decide what is most normal, most routine, and that thing needs to be tied directly to those real effects.

Sometimes we refer to “domain knowledge” if our customers have special expertise, and we need to know that stuff, at least a little bit, so we can relate to our customers (and it’s usually pretty fun to explore someone else’s world a bit). However, the most important thing our customers know, that we need to discover, is what will solve their problems. They don’t know it in their minds — what they describe that they think will solve their problems often doesn’t actually. They know it when they feel it, when they somehow interact with our software and it gives them agency and amplifies their effect in the world.

Our software works when it empowers people to solve their problems and create impact. We can measure that. We can watch that happen. For those of us who have experienced that as software engineers, there’s no going back. We can’t write software any other way.

Customer stories, first hand knowledge from the people whose problems I’m solving spark my imagination, but I’m careful to use those stories with context from quantitative data. I love the product managers who tell me about rapidly expanding markets and how they relate to the use cases embedded in those stories, and research teams who validate whether the story I heard the other day is common across our customers or an edge case. We build software on a set of assumptions. Those assumptions need to be based on reality, and we need to validate early and often whether the thing we’re making is actually going to have a positive effect on reality.

Customer stories are like oxygen to a development team that works like this. Research and design teams who work closely with product managers are like water. When other engineers can’t explain the customer use cases for their software, when they argue about what the solution should be based only on the technical requirements, sometimes I can’t breathe. Then I find the people who are like me, who work like this, and I can hear a heartbeat, I can breathe again, and if feels like this thing we are making just might be awesome.

]]>
https://www.ultrasaurus.com/2017/06/customer-driven-development/feed/ 0