I’ve been living in San Francisco for more than 2 years. I wasn’t an entrepreneur when I moved here and I’m still not. Hopefully one day I will be, but I guess those 2 years have been more of an introduction to entrepreneurship. Discovering the tech startup world in San Francisco has been far more fulfilling than my last 5 years studying in college. Coming from France, attuning to American culture has been a long process for me, and it has taken some time for me to embrace it. Here are some takeaway lessons I’ve picked up over these last years.

American Story Telling

The simple example I have in mind is that we (as French people) don’t know how to talk about ourselves. Actually, I feel more comfortable to speak about myself in English than in French, probably because I first learned to tell my story in english. So you might ask why I didn’t learn to tell my story in French first? I believe it’s culturally and linguistically different. French is a refined and elaborate language and we really care about our look but sometimes I feel like it’s too much, and we don’t get straight to the point. For instance, at the end of a formal letter, in English we usually write “Yours faithfully” or “Sincerely“, while in French we would write “veuillez agréer, Monsieur Dupont, l’expression de mes sentiments distingués“, which translates to “Please accept, dear sir, the expression of my most humble greetings“. In the end, our desire to appear so eloquent adds many barriers and limits our effectiveness as story tellers.

Don’t get me wrong! French is a beautiful and complex language, but when the matter is business or to market a product, French doesn’t sound so great. Just check this iPhone ad taken from apple.com and apple.fr:

There’s 1 thing that I would point out: it’s “dernier cri” which means “latest fashion”, my guess is that “dernier cri” was the less worst translation they could find, that expression is way too complicated and it’s not commonly used in french, and ironically to me it’s almost old fashioned to say “dernier cri”.

American Positive Thinking

The most striking thing to me since I’ve been here is how positive people are day to day. Here I have noticed everyone gets excited for all sorts of things: trying a new restaurant, a new product launch, etc. In French, we don’t have any equivalent translation to say “I’m excited”. The closest equivalent would be “Je suis enthousiasme” (I am enthusiastic), but I would never say “Je suis excité(e)” unless you are talking to your boyfriend or girlfriend with a sexual connotation :)

Lack of French Role Models

This lack of our expression of excitement about anything could turn against us. How could you build a successful company if you can’t show how much you’re excited about it and how much you believe in it? At Miso, sometimes I feel like I am the most skeptical person because I don’t always know how to show my excitement about something. It becomes alarming if you ask me if to name any french entrepreneur role model… Certainly not Bernard Arnaud (CEO LVMH), neither Arnaud Lagardère (Groupe Lagardère). I’ve a lot of respect for them, but it’s not that kind of entrepreneur that I would admire.

Xavier Niel (CEO Free) would be the first I would name, he’s one of few willing to make a difference, willing to change how wireless market works in France, that by the way one of the things Americans should take example of. Also I’m pretty sure there’re a lot successful french entrepreneurs out there, it’s I think we don’t have enough inspiring models in France, Michel Lévy-Provencal (CEO Joshfire) or Stéphane Distinguin (CEO faberNovel) could be good candidates, it just a matter of exposure.

On other hand if you ask the same question for americans, that list can be very long. If I had to pick one, I would name Kevin Systrom (CEO Instagram), I’m still amazed how successful Instagram has been. Only a 2 year old company and less 10 employees with 25 millions users and only on iPhone!  I would recommend to watch this interview to see an example of a good role model.

Conclusion

For the time being, I enjoy being a software engineer at Miso and watching Somrat and Tim as entrepreneurs. It is inspiring to me and to the rest of the team, and eventually one day I will step up to try for myself. First things first though, let’s change the way that people watch TV. #drinkthesoup

Last month we released YAMLRecord, a lightweight way to persist a small dataset into a simple YAML file which is fine if you’ve only one app server and you keep the YAML file stored locally.

As pointed out by Nelson Hernandez, YAMLRecord presents a problem when you have multiple application servers because the file can no longer be stored locally on a single application server. The problem is that if a change occurs in one of theses servers, the YAML file would have to be updated on all the others or stored in a new location accessible by all the servers.

To address this issue, the goal was to find a way to move the YAML file away from the app server and store it somewhere else that can handle access from multiple instances. With Nathan, we brainstormed and listed several solutions we could implement to allow us to scale out with YAML Record:

1. Store YAML file on S3 and cache the data locally
2. Use NFS and mount a shared volume and store the YAML on that volume
3. Serialize YAML content in an existing persistence store such as PostgreSQL or Redis

Why Redis?

We chose to augment YAMLRecord with a pluggable “adapter” system that supports storing the YAML content on Redis. We would then move the YAML data from the file system to a redis-backed store. This may seem to be an odd choice but we have a number of simple lightweight YAMLRecord resources setup and we wanted to keep this system in tact for the time being.

The first solution with S3 and memcached seemed relatively sound in which we store the YAML files on S3 and then update them there each time a change is made. This solution seemed to be an issue because we would be forced to leave our LAN and access S3 each and every time we wanted to update the YAML data. Also, to retrieve the YAML data from a remote location each time seemed a bit overkill.

Using NFS shared volumes is the more “traditional” solution. Simply setup a shared volume and mount the YAML files to each application server. We opted not to use this approach because this would be yet another “moving part” in our system that we would have to manage as we deploy servers. We wanted to use an existing system if possible so that additional complexity wouldn’t be introduced.

We ultimately felt that the last solution where we would allow YAMLRecord to support different storage adapters would be a decent approach. We felt this made sense for our infrastructure which was already set up for redundancy and backups on PostgreSQL and Redis. When we built YAML Record, it was to avoid the heavy-ness of a SQL Database, it didn’t really make sense to pursue a storage adapter in that direction yet. We felt Redis would be an easy to use storage adapter with the key being the YAML file name and the value being the serialized YAML data.

What’s new on YAML Record?

With Redis as a solution to scale out YAML Record data, we also wanted to keep the option for a local store with a simple file. We came up with this idea of swappable adapters which allows YAML Record to be modular.

In order to use the Redis adapter it’s quite simple, you just need to pick which adapter you want to use in a model:

class Team < YamlRecord::Base
  # Declare which adapter you want to use
  adapter :redis, $redis # $redis is your redis client

  # Declare your properties
  properties :name, :role

  source "team," # Will store data in a key "yaml_record:team"
end

What’s next?

Here’s some ideas we want to achieve soon:

• Be able to specify type for properties
• Add validations
• Add timestamps magic fields like on activerecord
• New adapters build by you? :)

Why YAML Record?

At Miso, we occasionally ran into situations where we wanted to persist simple data to a text (or yaml) file. Examples include landing page email forms, contact forms, feedback forms, about us “team” pages, etc. In these situations, we wanted a way to persist data to YAML and easily view the results in a text file but also manage the data through forms and controllers as any other data. To achieve this we have created a YAML-backed persistence engine called YAML Record that allows access to YAML based data using a familiar ActiveRecord API.

If you have a small amount of data to persist which changes infrequently but that you do need to update from time to time, you should investigate using YAML Record. In other cases where you have frequently updated information, several query requirements or a medium/large set of data, a SQL or NoSQL solution would probably be a better fit. Using YAML for persistence doesn’t work in every case so use this approach wisely.

YamlRecord is a standalone, simple and lightweight way to map your data from a yaml file, and can easily be integrated along with ActiveRecord and we try to provide the same APIs. On the other hand if you’re using DataMapper, I would recommend checking out dm-yaml-adapter which allows for similar functionality.

How do we use this at Miso?

We have several use cases for YamlRecord. The first one is to persist our team members profiles on our about page. Using YAML Record, we can easily add, update or remove any of this information with a RESTful architecture and standard controllers. We even implemented full DragonFly support with YAML Record so we can link up to each team member with a picture. I’ll probably cover this functionality on my next blog post.

In another case, we use YAML Record for our FAQ. From an relational data perspective, storing this questions requires only a single table without any relationships to other tables or any indexes. For cases like this, a SQL solution and the overhead of creating a migration and a table doesn’t always make sense. We definitely could use a SQL table, but having one with 10 rows and only 3 columns seems almost silly.

------------------------------------
|  id  | question | answer         |
------------------------------------
|  1   | foo?     | blablabla      |
------------------------------------
|  2   | bar?     | blablaaaaa     |
------------------------------------
|  3   | L33t?    | Y3s            |
------------------------------------
|
...
|
------------------------------------
|  10  | n00b?    | n0!            |
------------------------------------

I would rather have a YAML file which looks like the example below. The main upside of using a YAML file is Rails is going to load entire file in memory once, that way your application doesn’t need to go back and forth to read your file each time.

---
- :id: 08cc5f757b26903b9e7b6fcc3a3fbe
  :question: foo?
  :answer: blablabla
- :id: 4f2e73f896d0443c2b66f57cbdb2bb
  :question: bar?
  :answer: blablaaaaa
- :id: 5197b037524a1629d27c69f7aa9891
  :question: L33t?
  :answer: Y3s
- :id: f77c91577af4bf9b1e994e1b5b9ecd
  :question: n00b?
  :answer: n0!

Using the same APIs as ActiveRecord

Here’s a quick sneak peek on what you can achieve with YamlRecord. Given a class HotGirl:

class HotGirl < YamlRecord::Base
  # Declare your properties
  properties :name, :sex_appeal_rate, :age

  # Declare source file path (config/hot_girls.yml)
  source Rails.root.join("config/hot_girls")
end

Here’s some of actions you can do:

# Create your instance as on active record
@hg = HotGirl.new(:name => "Jennifer Anniston", :sex_appeal_rate => 75, :age => 42) # @hg
@hg.save # => true

# Alternatively
@hg2 = HotGirl.create(:name => "Scarlett Johansson", :sex_appeal_rate => 92, :age => 26)

# You can get your items easily
HotGirl.all # => [@megan_fox, @jessica_alba ...]

# Update the record attributes
@megan_fox.update_attributes(:sex_appeal_rate => 100) # => true

# Destroy it
@miss_usa_2011.destroy => true

We tried to provide all essential APIs ActiveRecord provides and more are coming. If you want to know about the available APIs, you can find it on the README or Rdoc

Feedback?

We would love to hear your feedback on this concept to persist data to a YAML file in certain simple cases and about how we can improve this library in the future. The source code is available on Github and we welcome all patches and pull requests. Feel free to share your thoughts about it.

Conclusion

We really believe this concept of persisting data in YAML file makes a lot of sense for us in particular scenarios. Building this was actually a challenge for me as it was my first gem. I want to thank Nathan for his support building the gem and I really learned a lot in the process. After all, I guess we did it for fun and as an experiment to see how this would work.

We also found these 2 gems in same vein as YAML Record, which are worthwhile to check out:

• Datamapper GoogleSheet adapter
• Gitmodel

After reading these blog posts on why new graduates should or shouldn’t join a startup, I feel I should give my insights based on my past experiences as well as on my experience at Miso. First of all, let’s put that statement in context, as I have only just started my career and I’m not yet graduated. However, I’ve already worked for more than 1 year (full time and part time) at Société Générale as Tech Op, which is one of the biggest banks in Europe, and all of my past internships have been in startups…

After coming across why we shouldn’t join a startup blog posts, there are 2 points I would agree with him on:

• Startups are not for everyone, especially tech startups, everyone isn’t a “geek”, neither excited by new features on Twitter, that’s a fact.
• Both posts quoted Steve Blank: “It’s your curiosity and enthusiasm that will get you noticed and make your life interesting.” It’s kind of obvious, you will enjoy your work if you’re passionate about it.

However, I disagree with most of his other ideas…

1. Passion is the ultimate competitive advantage.

Yes, in both startups and corporations you can work with passion, the main difference between these two is that in a startup, you are sure to work with people who enjoy what they’re doing, and that’s not always the case in my past experiences in corporations.

His main argument is that in large corporations, employees “can afford to have highly specialized jobs filled by people who only focus on one particular component”. Ok I can understand that, but to me being close in his skill area, it’s to me like communitarianism because you can’t learn and you can’t expand in your field. At Miso even if my official position is Rails Developer, sometimes I had to sketch out some design for new features. Basically my point is yes, in startups you have to assume many roles, but it’s necessary, it teaches you to think globally and not be focused on only your code.

2. Leverage

Have a big companies name on your resume always gives you some credibility, that’s true, but I would rather have an unknown startup on my resume which had failed and be able to explain why it had failed, and on the other hand if you have worked for a successful startup, being part of the small team looks significantly more impressive.

3. “Startup years are like dog years”

It’s been already 2 months I’ve been working at Miso and I feel like it was a year. It’s an intense internship, I learn so much things not only in ruby, in product side, and in community management… I’m not claiming I’ll be a guru of these domains at the end, but’s it’s definitely improving my culture and above all helping me to understand why I’m coding these new features.

4. More Money

If your first motivation is making money, don’t work for a startup… I turned down a better offer in terms of salary, to accept the Miso one because I feel it was and is the right place to learn. I don’t know if Miso will be the next big hit in the valley but anyway, I don’t care if we fail, again the most important thing it’s to understand why you failed.

“If you make meaning, you’ll probably make money”- Guy Kawasaki. I really believe this quote can be applied as employee not only in a company context, I really need to know why I’m doing this feature, for which purpose. At Miso, the purpose is simple; we want to “Make TV more fun, change the way how people are watching TV”. During my time at Société Générale, I didn’t even know what the company actually did. I worked in a subsidiary called Société Générale Securities Services and to this day, I still don’t know what it’s doing. The worst part was not one of my colleagues was able to explain it to me either. The only thing that mattered was to keep the servers running, beyond that I never was encouraged to understand the larger picture.

5. Relationships

It seems in a corporation you can build a network of “hundreds or thousands of coworkers”. If it’s the case, it’s a bit curious to build this network only within the company. I believe in openness and at Miso, the engineering team tries to be close to San Francisco Ruby Community. We attend meetups, hosting ruby workshop and generally try to be involved. There are 2 goals behind this, promoting what we’re doing and also promoting ruby. Most of all it’s about sharing and improving our culture. You could learn for example what’s the best practices in hot new startups just by making a connection. This gives you some insight on what you’re doing. It’s a win-win situation to be involved outside of the narrow focus of your company.

Relationships in startups with your colleagues are not the same as in a corporation. The day-to-day interactions drive more than a simple colleague relationship. I’m not saying your colleague will become your best friends, but I definitely know I will stay in touch with my Miso colleagues after my adventure here. And I still hang out with my lovely pariSoma friends as well.

To conclude, for these reasons I definitely know that I don’t want to work for corporations. On the other hand some people needs a “safe” work because their situation requires it, I can understand that too. But that doesn’t mean startups can’t work with “corporations”, we need them and they need us. We work with many larger organizations here such as Fox, Logo, Showtime, etc. The most important thing I believe is that working for a fast paced startup is worth trying because you will rapidly grow your experience and learn about things that you never expected.