rememberlenny

Senior meets junior lessons learned, and some thoughts about the future of remote work

December 31, 2019 by rememberlenny

High level summary

Last month, I setup a brief survey on Typeform and submitted it to ProductHunt as a project called “Senior meets junior”. Senior meets junior was described as a project that would allow engineers to collaborate together over side projects. Junior engineers could collaborate on real projects to upskill, while senior engineers can improve their mentorship abilities and receive more help on their projects. I’d like to formally share the stats around the response and a few surprising results that I will be considering for the next steps.

https://www.producthunt.com/posts/senior-meet-junior

Breakdown around statistics

After submitting the Senior meets Junior survey on ProductHunt, I received a 186 submissions from both senior and junior developers looking to collaborate on side projects. Of this group, approximately 75% were self-identified as junior developers, and 25% were self-identified as senior. I was able to meet with 19 individuals out of the hundred in 97 people who signed up. All of the 19 individuals only two people were actually from developed countries (US and France), but even one of them were actually traveling abroad, so I actually spoke to 18 people from emerging markets around the world. I’m not sure if the name ”Senior meets junior” is a term that is not appealing to Americans or if the idea of mentorship is more appealing to people of foreign backgrounds, but I was genuinely surprised by how many more people from developing countries signed up to the service. I definitely expected more junior engineers from developed markets, who were interested in upskilling.

One more note along the ratio of senior and junior engineers. When reviewing the applications, I searched the background of each user and noticed that many of the individuals who said they were junior developers were working as seasoned engineers. I couldn’t figure out if people were misidentifying as Junior developers because they wanted to work on other people’s side projects, or if they truly believed that their abilities were not at a senior level.

From a statistics perspective, the most languages people wanted to work on was JavaScript. I asked the question “What technologies is your project based on, or if you are junior, what technologies are you comfortable working with?”. Following that was Python, and then Java. As you will see in the chart, 58.6% people said JavaScript, followed by 50% in Python, and 21% in Java. Ruby, Rust, Scala, and a number of other languages all scored less than 10%.

Interestingly, when asking people where they needed the most help, most people said Backend development. The question was “What areas do you expect to need the most help or if you are junior, what would you feel comfortable contributing to”. Considering so many people wanted to learn or contribute JavaScript, the sheer amount of Backend development help needed was predictable. About half (57%) of the people who wanted help in a certain area also shared they wanted to improve their Frontend application development. This is consistent with the Javascript interest.

One of the questions I found most interesting was around how much time someone felt they needed to be productive. Similarly to the time is takes for a hired engineer to start contributing code on a new code base, I wondered how much mentorship a junior engineer would need to start working on a foreign project. The question I asked was: “How much mentorship and direction can you provide someone who works with you? If you are junior, how (much) mentorship and direction do you think you need to be productive?”. In response to the question, and surprising majority said they only need 1 to 2 hours a week of mentorship to start contributing to a codebase. This is a pretty small amount of time, relative to how much one person can do to contribute.

Areas that I was surprised about

The first area that I was surprised to learn with how dramatic the different the engineer pay rate is outside of the US, and how similar it is in across many developing countries. I learned that in Ukraine, India, Georgia, Spain, Russia, Turkey and Nigeria, the average pay for a Year’s engineering salary is between $30,000 to $15,000 US dollars a year. This means that in one month many Engineers are making less than $2,000, and many are making less than $1,000. This is compared to the regular salary of a US engineer who makes up words 300 or $400,000, or a recent college graduate who can very quickly, man north of $100,000 USD.

https://twitter.com/rememberlenny/status/1204074924576563200

To imagine that there are so many more engineers across the world than there are in the US, and that many of these are English-speaking, and that many more are receiving the same educational resources as those engineers in the US, I cannot help but imagine that these foreign workers will soon be replacing domestic engineers in the US. When I think about how much remote work has been discussed in the last few months, I can also see that the infrastructure for hiring remote workers is maturing and will soon allow for more and more remote workers from developing countries to contribute to domestic projects in the US. I also recognize that many foreign workers may not need anywhere near a US engineer salary, and would potentially be very satisfied to work at the higher-end of their local salary range. When comparing this to an engineer in the US who works at the lower-bound of the salary range for their domestic peers, I imagine the foreign worker to be significantly happier and willing to contribute more.

https://twitter.com/rememberlenny/status/1208068305141018625/

The second area that was quite surprising was around the U.S. engineers that I spoke to who were unhappy about their work and didn’t like work that was primarily based on taking a design to translating it to code, or processing bugs in a bug tracker system that did not require any critical thinking. I imagine that this kind of work which is not desired by skilled laborers in a domestic Workforce, would be very easily translated into Outsource or remote work. I believe that the growing need for constant maintenance and simple types of engineering tasks will reveal the value of having an accessible remote Workforce that does not need to be highly engaged with decision making.

Third, there is a large number of people who are quite adept at the current Frameworks (read: React) and programming languages (JavaScript, Python, Java). These people would like to grow in our less around programming skills or computer science foundation’s, and their interest is more around establishing best practices and means of collaborate. These remote Engineers are people who know how to write code and solve problems for clients, but still need to learn how to deploy production applications or optimized server configurations for scale. These kinds of engineers are ideal for collaborating with other developers, because they are interested in learning things that are not explicitly taught will online but would be able to contribute to a code base if given explicit instructions.

https://twitter.com/rememberlenny/status/1203732117131268096

Lastly, I was surprised that there are a large number of Junior developers were able to learn quickly and could become employed across the world. In many cases around the U.S., coding bootcamps can take someone who has no experience, and help get them to a point where they are able to get a job at a tech company within three to four months of accelerated learning. I noticed many junior engineers across the cohort of users who also could become employable with self-study within a six-month period. I was very naive to think about how on technical I imagined some of the participants who signed up would be from developing countries. I was surprised around the fact that most college graduates are all learning the same things that the US level college graduate would be learning. This means that a computer science student will be focused on machine learning, or an electrical engineering student will be working with Arduino and raspberry pies. Given that this is the same technology that a domestic student would learn from and that the skills are identical, there is no reason why these individuals could not come highly employable in a short period of time as well.

Conclusion

Overall, I strongly believe that remote work and contributors from around the world will meet a crossroads soon. While remote work in the US is becoming more common, I foresee many more engineers from countries around the world contributing to code bases in the US. This would mean that the tooling that helps coordination will likely become more important, and the areas of work that are centered on decision making and executing will likely be separated or clearly organized.

I also believe that the sheer amount of income that current software engineers command is disproportionately high when compared to the education or skills needed to complete certain roles. While I am not sure if the high-salary is necessarily justified, I do think a number of market forces (VC investment, high return of certain software businesses, demand for engineers who are skilled at new technologies that haven’t existed long enough) are likely the reason for driving up engineering value. Not all engineers are necessarily returning the value on their investment, so I could imagine different tiers of engineering work to be more explicitly defined outside of the terminology of senior or junior. The larger tech companies near are already different tiers of engineers from being a principal engineer, a lead engineer, or different tiers of software engineer.

I’ll be moving forward with trying to interview more of the Senior meets junior sign ups, and expect to continue expanding the cohort from engineers to other fields such as design or product management. If you or someone you know may be interested in this project, please sign up at www.smj.dev, or contact me directly at [email protected]

Please excuse the grammatical errors. This was written using dictation, and followed with slight edits.

Thoughts on side projects

December 19, 2019 by rememberlenny

The friend is this picture is not the one I reference below. But we both thought it was a good idea to buy Google Glass when it came out.

I recently visited my best friend from college.

We were both city boys who caused trouble as teenagers, and connected over our free spirited willingness for fun. Since our friendship began 10 years ago, he has taken up farming and lives in Oregon on a nine acre plot with crops, animals and a seasonal business. I ended up in New York city, married, and working at a tech company as a programmer. Both of us studied philosophy and literature, both of our lives took unexpected directions, and I think that we both ended up exactly where we want to be. At least for the time being.

I wouldn’t necessarily call the farming a side project, but I also don’t think my friend will be a farmer for his entire life. He spends his days and nights farming, but his dreams are around writing and his real income comes from highly successful real estate deals. If all of his time goes toward one thing, and all of his money comes from another, then which is the side project and which is the job?

Similarly, my income comes from a consulting contract, but the majority of my time isn’t spent at work. In one sense, this is because I found a great company to work with, but in another it is because I prioritized finding a source of income that allowed me to spend a lot of my time on side projects. In my own defense (not that I need one), my time spent on projects makes me much more impactful in the other areas that I end up working in. But I don’t consider them work.

Given the two cases where a side project ends up becoming the main allocation of time, I conclude that a “side” project doesn’t necessitate a minor allocation of time.

For the past seven years, every winter, I have taken on a side project.

In 2013, I traveled around the US and built an artistically laid out website that described an educational pedagogy. In 2014, I went to India and learned enough Objective-C to make an iOS app. In 2015, I made a hotline for people to share their breakup stories. In 2016, I built a ruby API and bot that traded stocks (very poorly). In 2017, I built a deep learning machine and trained some amateur image recognition models. (Surprisingly I never used this to mine crypto.) In 2018, I indexed millions of street art images and built a web application to explore them online. All the while in between, I was playing around with unfamiliar tech and building out personal projects for fun.

This winter, I haven’t “built” anything, but I have been thinking a bit more deeply about what the output of all my side projects have been. I have a nagging feeling that while each project was unique and fulfilling in its own right, I don’t have any concrete products to point to. Once the project becomes too expensive (or no longer interesting) to maintain, I often let domains expire or spin down servers.

My usual process is this: The output of the side projects is a website, possibly with a registered domain, and some efforts to gather attention. This results in a boost of page views/downloads while the promotion efforts happen (ie. Reddit/hacker news posts), but then eventually drops to a crawl. The remaining traffic normally comes from search, and otherwise never surges again. At the point that the traffic doesn’t feel worth the small but real cost, I start sunsetting the project.

This brings me to the question of why I do side projects, and also what more I think could come out of the projects.

While reading a great book about note-taking (How to take smart notes by Sönke Ahrens), I was intrigued by the idea that all notes should be taken with a purpose in mind. In the book, Ahrens states that notes should be taken with the mindset of needing to write about the material being read. In the same way, maybe defining clearer purposes for side project, could ease my feeling that more could have come out of old projects.

(I preface this thinking with an important point: Doing a side project for the sake of doing it alone is absolutely a good enough reason. I think if every side project must have a predetermined purpose or end goal, you will end up a person with boring side projects. And you would likely become a boring person. For example, if you feel all side projects need to result in becoming a business or passive source of income, then the pursuit itself will result in a series of unoriginal projects that are hard to maintain over time. Personally, doing projects out of sheer interest and a desire to learn or experiment has been the greatest force for sustaining my excitement and investing my time into producing something new.)

Now, let’s assume there is some definition of a side project. It’s a pursuit of some idea, which, in my case often revolves around technology, and results in a product (ie. an app, hardware), a community, or a collection of knowledge (ie. research, blog post, dataset, academic article).

That being said, the yearning sense of looking back at projects and not having some clear value to point to s concerning to me. With some projects requiring well over 100 hours, and in some cases hundreds of hours of time, I do wish I could point to something concrete that crystalized my effort.

Value I have derived from side projects:

I can honestly say that the projects I decided to work on made me more interesting and have something worth talking about.
If I was just doing “work”, I would feel dull.
In the process of learning something new for a project, I regularly made new friends to expand my knowledge and perspective on a problem.
Along the same lines of being “interesting”, by making something new, I felt I established some authority as a developer or product maker.
I established more confidence in my ability to contribute to other people’s projects.
When in work atmospheres that were less than exciting, side projects gave me something to be motivated about when work was not.

Moving forward, concrete things that I’d like to do

First, I need a lessons learned blog post and some kind of summary of the project. I don’t know if this is a series of gifs and screenshots, or some kind of gallery that can be previewed. Or at least a document or single place of reference that explains the project would be great.

Second, if data or an untapped area of interest is involved (ie. my street art project), I strongly feel publishing in an academic journal article would be possible. I don’t know what the process is like to submit to an academic journal if you aren’t affiliated with an academic institution or research entity (except I sometimes treat my projects as research entity), so understanding that early and then pursuing the project accordingly could be interesting.

Third, wouldn’t it be nice if all side projects resulted in some $$$? It’s not possible and shouldn’t be the goal in most cases, but in some cases the project could be wrapped up as a deliverable to someone who wants to buy it. When doing explorative projects, there are certain decisions I have made that I didn’t consider too seriously. If I had considered a sale of the overall codebase/community as an original goal, I imagine I would make different decisions along the way.

Anyway, I’m sure I will come up with something to work on this winter. If this year’s project doesn’t survive a year from now, and doesn’t become an academic study, and no one buys it, I think it’s still okay. I’ll still be happy working on something.

Goodbye 155

December 6, 2019 by rememberlenny

Yesterday was the “Goodbye 155” celebrating the next steps for Orbital’s historic 155 Rivington St location. More than anything, the night felt more like the closing of a community church, and the gathering of its congregation. The evening was designed to provide space for people to share their experiences and lessons learned. It was very “Gary”. I didn’t personally share anything, but took notes throughout the evening when I remembered long lost memories and weird experiences that made Orbital special to me.

Gary and Christina possibly planning their 1K

First of all, I came across Gary through a seemingly unique set of events. I met Gary after being invited to co-work with him and Jed at a coffee shop in k-town, after lunch at a Korean restaurant. I had just met Jed in Florida at a JavaScript conference, and soon after saw him again in Berlin, when I decided to attend the sister conference the same year. To cowork together, Gary had a fascinating hotspot device, called the Karma, which touched on my tech virtues of interesting new gadgets.

Jed doing everything he can to hold back from singing “It’s So Hard To Say Goodbye To Yesterday” https://www.youtube.com/watch?v=-w6m-nhUcos

I got to learn more about Gary and the class he was teaching at SVA, where students were tasked with making a product that create $1000 in revenue over one month. Fascinated by the idea, I kept in touch over email, trying to find out if I could audit the class or have him send me the materials. Eventually, this resulted in learning about Orbital and it’s first program to help provide a structure and space for people with side-projects to create businesses. I loved this idea, had a few side projects, and had recently discovered the startup literature that floated around the internet.

I had just arrived in New York only a few months before, and unknowingly, after reading a series of Hacker News posts and writing from Paul Graham, I was convinced that doing something in the startup space is my calling, but didn’t know exactly how or what to do. As I was establishing my career, I thought Gary Chou was the East Coast Asian Paul Graham.

Before making that connection, I also was trying to figure out what was wrong with Gary. I couldn’t quite pin how a random person would get a multi-year lease on a three story New York city building, with no particular business plan. Very Gary.

I have incredible appreciation for Orbital and the immeasurable effort Gary and the others put into building the community.

A random list of things that I won’t forget and give me great joy to think about.

155 Rivington has a (and hopefully will continue to have) historic piece of punk rock graffiti. Not only, it was also used for a Rancid music video and the graffiti piece itself has been there since.

http://fredbenenson.com/2014/01/19/digital-forensics-rancid-reas-kickstarter-hq/

For the last two years, I considered trying to figure out how to plan a wedding in New York. I kept thinking Orbital was the perfect kind of place to do that. My wife and I ended up not going that route. But someone did! Proof 155 Rivington isn’t just a coworking space. Who gets married in a coworking space?

My first VR experience was at Orbital. Orbital attracted people with a wide range of interests. Of course, some of those were in deep technology. One member, Shawn Cheng, who was passing through the space when I was there had a passion for helping people experience their first major VR experience. For me, that was Kingspray, the VR version of spray painting on a wall. Surprisingly, it was amazing and I spent well over an hour “spray painting” a mural. Where else can you take a break from working and get up to spray paint a VR mural?
I remember also with Shawn (VR guy mentioned above) enjoying a cigar out on the back porch of Orbital. Soon after, I was directly reprimanded for not being allowed to smoke in the back patio. Fond memories of Gary’s reprimands.

When I realized I was interested in Machine Learning, I had the bright idea of building a computer to train ML models. Gary let me use the space to ship computer parts, build a computer, and also for quite a while he also let me house the machine for free. This was around the crypto craze, so I strongly believed that Gary thought I was mining bitcoin. (I wasn’t mining crypto Gary. I promise.) It speaks to his willingness to support others.
I remember I would spend weekends and late nights at Orbital. One late night – I think it was a Saturday – the bar downstairs was pumping some kind of club music and I was on the second floor piecing together the desktop computer parts that had finally arrived. It was almost midnight and I was convinced I was going to be alone until I closed up, and surprise – two Orbital members showed up with suitcases – arriving from a recent trip. It was an odd exchange – me with a huge table full of computer parts – and them not expecting to see anyone so late in the evening.

Setting up a deep learning machine December 2017

At one point Orbital didn’t have any air conditioning (or if it did there was really old). I remember arriving to 155 one day and seeing a stack of 6-8 air conditioning units that were donated. It was an odd sight that I still remember vividly for some reason.
July 4th, I remember watching fireworks by the river from the roof. I don’t remember exactly why, but I remember spending time on the roof for a number of other occasions as well.
Orbital is a physical space, but somehow I keep encountering Orbital people in digital space. One odd experience was when I posted in a private Facebook group for OneWheel owners and a response came from Mike Ma, an Orbital member who happened to also ride OneWheels. That led to a number of fun excursions riding around Prospect Park and the Cloisters.

Beyond the random list, I came to New York not having any roots, and eventually shifted toward making incredible friends and collaborators. Much of that stemmed and came back around to Orbital. My last three jobs were all related directly or indirectly to Gary and Orbital. My current job contracting with Google, I got through a relationship that I created from the Bootcamp – when Gary encouraged us to meet people who are “experts” – and also directly from the #jobs channel in the Orbital Slack. The job before, was a “pivot” for me, where I worked at a machine learning focused company. Gary encouraged me to take time to write out exactly what I wanted to do, what my path was up to now, and explain where I wanted to be. By going through that exercise, it became clear how I could get the kind of job in an industry I was interested in, while also being able to articulate my value to someone. And before that, I worked in the federal government, where I was encouraged through being around so many Orbital members, to do something that was more than just a paycheck. The search for something that was meaningful and contributive to the people I worked with was what made me think I would even consider the opportunity.

In other words, thank you Gary for everything you put together, all the financial hurdles you jumped through to make 155 possible, and the unending love you put into making Orbital so special.

How Public Art works

March 7, 2019 by rememberlenny

Details on my React-Native iOS application backed by a Ruby on Rails backend and some Python Jupyter notebook scripts

Public Art is an iOS application that helps you discover new nearby street art.

I’ve been working on this project on my own, but it has a lot of technical moving parts. I will explain how all of the moving parts work and what I’m planning to do in the near future. By the end of this article, I hope you have the awareness of recreating the same behavior for your own project.

Background

First of all, the reason I am working on a street app discovery tool is not to build the next urban media empire.

Although that sounds nice. I started trying to preserve graffiti and street art with as much associated metadata as possible for future art connoisseurs.

At one time I was trying to make a street art media empire, through questions. I wrote a series of fragmented blog posts in 2013, that later grew into this. Most of the posts can still be found here: http://newpublicartfoundation.com/

Given the rate at which photos are uploaded online, I felt it would be a great opportunity to preserve the otherwise transient form of cultural expression that is found around the world. I don’t have a secret surveillance agenda or political motive. I understand the privacy implications of preserving this information, as well as the complicated legal potholes involved.

That all being the case, I feel it’s important that someone preserves street art for the future, and that’s what I’ll go into below.

Frontend

The front-end portion of Public Art is a mix of an Expo based React Native application with a few interspersed Ruby on Rails and React web pages. The React Native application is a stock Expo application with a modern Redux/React Navigation architecture.

Beyond Redux and React Navigation, I used a number of packages to help with speeding up development. I used a UI library called NativeBase which provides some helper components, but eventually transitioned to using React Native Elements. Both of these libraries were not necessary, but provided enough structure to speed up my process. The main tool needed in any good UI library is a good layout structure. For React Native, the most common layout technique I saw was to use flexbox.

The app is composed of primarily loading images and displaying mapped points. I initially tried to use a few helper libraries for gracefully loading images, but eventually found the best performance around using the React Native Image tag as is.

For the map, I depended on the Expo framework’s React Native Maps integration. I explored ways to use Mapbox, but to stay within the Expo ecosystem, decided not to. That being said, the React Native Maps is a great library with all of the application control needed highly responsive maps.

As mentioned above, I used Redux for the primary datastore of the app. For managing the application’s side effects, I decided to use Redux Saga. In the past few React applications I’ve built, I aired on the side of using Redux Thunks. I noticed in my last project that the ability to test Thunks was overly complicated and wanted to pursue a more testable solution. After some research, I decided the best bet was Redux Saga. While this took getting used to, I do see the value and intuitive nature of the Saga based datastore/side effect architecture.

Backend

The back-end of Public Art is a combination of a few different “micro services”. In other words, it’s composed of a few web applications that talk to each other over http requests. In addition, I have a linux box that runs a series of shell scripts and cron jobs that provide important functionality that will eventually be replaced with another “service”.

The primary backend and authentication works as a Ruby on Rails application running a few gems which I’ll explain below. The Rails app runs on Heroku and uses the Heroku Postgres and Redis hosted services. While this is a costlier way to operate (especially because I have free credits in two different hosting providers), the convenience really makes a difference. It’s easy to deploy, manage credentials, and spin up/down workers.

For authentication management, I use the ruby gem Devise. Devise is a familiar gem for any Rails developer that needs any kind of user profile/authentication system. In my case, the Devise instance is setup with a User model, but all the views and business logic is triggered with a token based REST api. This was tricker to get setup than expected, but eventually became the most flexible way to control user activity.

For image uploads, I use the ruby gem Shrine. Shrine is a modern implementation of some other common image management gems like Carrierwave, Paperclip, and Refile. The Shrine gem plugs into Amazon’s S3 and creates a simple means of caching image display formats for easy use.

For worker management, I use the ruby gem Sidekiq, which is a Redis job manager. Sidekiq handles all of my asynchronous actions, of which there are many.

Finally, for location related actions, I use the ruby gem Geocoder. Geocoder hooks into the Microsoft Bing location API to do reverse geocoding. This means taking a latitude and longitude point, and inferring a address.

Overall, the Ruby application handles all of the business logic for creating users, saving images, managing locations, and aggregating all of the information for the iOS frontend to display. All of this happens using various api endpoints that communicate with JSON.

Data/Content

The Public Art app provides a way for any individual to view street art images nearby. This is accomplished by surfacing images that are geotagged with a longitude and latitude point. The images are gathered by user uploads, which are few, and scraping Instagram, which provides many.

The current method of dealing with this is very fragile and will be updated accordingly.

I have created a series of scripts that use a major image uploading platform as a datasource for discovering new images. I use the user generated categorization system to identify content that may be associated to street art or graffiti, and index the content that is associated with location metadata.

To manage the scraping process, I use a python script that manages rate-limits to the image service. The python script runs as a linux process on my server and stores images in the file system. Once the image and the post metadata is downloaded, the script does a second server request for the location details. The location is stored on the image as an ID and requires a second lookup to get the corresponding coordinates.

The downloaded images are uploaded to the Rails application and indexed accordingly through a second python script that runs in a Python Notebook. This is very unusual for any python developer, but surprisingly works very well.

I have a Jupyter server running on my linux machine that iterates through the scraped images, uploads them to the Public Art backend server, then prepares the location metadata and updates the corresponding images.

Machine Learning

Originally this project was meant to have more of a machine learning component, but getting all the other parts right has been priority. I’ll be doing some stuff related to search and object detection soon. I’ll also be using more model evaluation to handle flagging content that isn’t machine learning.

Conclusion

I’ve been doing some additional experiments with ads and promotion which I’ll write about some other time.

Short announcement: App went out.

March 5, 2019 by rememberlenny

And I added 20,000 new photos in the last two weeks

Quick update to keep with the bi-weekly rhythm. This one will be shorter than others.

Last email I shared background details on the iOS application I launched.

You can find the app on the Apple app store now here: https://itunes.apple.com/us/app/public-art/id936484924?mt=8

If you have an iPhone, take a look at the “Search nearby” feature to view all the street art near you.

As mentioned in the previous emails, the app is composed of three main sections. In the “Map” browsing section, you can query your location and view images uploaded to Instagram that are nearby you.

Please let me know what you think!

Brief update for the last two weeks.

The main result of this past two weeks was bug fixing and getting the app out on the App store. I was having trouble launching due to numerous Apple app store guideline conflicts.

Now that it’s up, I have been working on various server related changes. I made some caching changes on the backend, so that I don’t have to worry about my location queries crashing my app. Every query is cached for 30 minutes, so major traffic wont result in downtime.

I set up a simple but important piece of a feature that will integrate some of the machine learning research I did before. I made a simple python server that can accept an image as a parameter, and return the image’s feature embeddings. This is going to be useful when building out a search utility for querying images based on the image content, as observed via the previously trained machine learning models.

You can see the open source code here: https://github.com/rememberlenny/publicart-ml-endpoint

Side note: I got some Public Art logo stickers. If you would like one, send me an email and I’ll ship you a few: [email protected]

Thanks for reading!

Weekly update February 19, 2019

February 20, 2019 by rememberlenny

Bi-weekly update for February 19th, 2019

Hey! I promised a bi-weekly update, so heres #2!

I did a lot of new development this past two weeks. To kick it off, I started experimenting with social media ads, selling physical products, built and released 21 versions of an app, majorly upgraded my backend application, and finally got the python scrape/import process working.

Heres the details:

Two weeks ago, I mentioned the progress on the machine learning tasks I was running, and I got the following message in the Pioneer August cohort.

In short, I was reminded that I can build a sustainable business around the art collected in this project, and was encouraged to consider what that would look like. I had previously written off the notion of selling anything, as I am more interested in the preservation of street art, but the suggestion alone got my mind racing.

I set up a landing page for selling street art posters, and set up a variety of social media based ads. I targeted people who are interested in street art and graffiti related hashtags, and set up a small but reasonable budget across the audiences. I noticed that a basic advertisement selling a poster for $26 got a decent. I did a very small (and unreasonable) experiment around “free” posters, to get a sense of how the general product was being received, vs the cost. Overall, this led to the next step.

I explored sourcing poster prints and found the margins of a totally hands off poster printing business to actually be very reasonable. Even with accounting for driving traffic with ads, there is a potential for building something that can generate income that could be funneled back to artists or photographers. I ordered one poster company’s print and was pleasantly surprised with the paper and print quality for the cost and photo resolution.

Shifting away from the new idea, I spent a lot of effort building out the actual street art tools. Last email was about the machine learning part of training a model to detect street art. This week, I focused more on building the tool to have user-generated content, and a pleasantly medium for consuming the images.

I decided to fully rebuild my original iOS app that was launched in 2014. Since launching, I hadn’t touched it, and it began collecting proverbial dust.

I had three parts that needed to be revitalized.

First, I needed a new app. Second, I needed fresh content to serve. And third, I needed a way to manage the content uploaded by users.

Regarding the app, I have been thinking about the execution of a good street art application for a while, so I knew what I wanted to do. Rather than focusing one something that manually needs managing and updating, I knew the only way I could be effective at building something was to make a self-updating, self-engaging app that used feeds of data to refresh itself to users. I also realize that the effective street art browsing method is not a regular cadence of opening the app, but rather a semi-regular summary email/notification that draws in an interested user.

I decided to use React Native and built out a four part app. The first part provides an editorially curated list of images from a larger community. Each day this create a fresh set of images that can be viewed. The second part of the app is a search based tool that lets people search for images in a specific place. The specific places are most interesting if they are your current location, but given that there are so many images being uploaded daily, so the third part of the app is a tool to view trending cities. Finally, the fourth part of the app is to allow users to upload content on their own and tag/label images.

Demo: https://youtu.be/wRWcbB3HfDY

Based on this model, I was able to get an authentication system up and running that allows users to sign up with a digital identity. This was built around a previous application I had, so I have a way to customize the experience of a user based on their browsing history and potential create tools around the user behavior. This system also allows me to have user generated content associated to an account, which is important for a variety of reasons.

For the daily update content, I took a shortcut and decided to feed images from the Reddit streetart subreddit. This group regularly uploads images at a steady cadence, so for now, this is my source of editorially curated content.

For the location search and trending locations, I was able to use my old API for street art in my 2014 app. The server that does the calculation of your current location and the nearest images to that point is still functional. The only problem is that all the old images are no longer accessible due to instagram’s platform changes in the past. As a result, I needed to rebuild the dataset around this server.

To do that, I have been scraping images for the past couple months, but haven’t been able to process them accordingly to refresh the local art detecting service. To get the images ready, I needed to make a small program that checked if the scraped images had associated location data, then upload the images to my application and create a location data point to correlate to the image. This was something I kept putting off, but finally took the time to do it.

I ended up writing the image uploader and location metadata association script in a python notebook. Being that it was such an iterative process to get right, I surprisingly found it useful. This was very unexpected.

I got the first batch of 10,000 images working and have many hundreds of thousands of images to process accordingly. Fortunately for the most recent batch, I scraped the images with location data. As a result, the images were slower to download, but I only had one remaining step after I was done.

For the remaining images, I need to add a step of checking if the downloaded images have corresponding location data. This shouldn’t take too long.

I have a few more possible tasks I need to figure out. One, is my image scraper saves images to a file system. The ideal situation would be to write a program that directly scrapes images and does all the other stuff needed to get the location data, and import the images into my application. Because there is so much rate limiting around the scraper, this is harder than it sounds. As a result, I need to make some kind of daemon that monitors my filesystem for new files and manages the scraped images. This daemon would ideally check which files were already checked/uploaded and then I would be able to let the scraper keep operating as it is.

Separately, I noticed that a lot of the newer images I have been getting have less accurate location metadata. I think this is part of the privacy/security shift on the Instagram platform. Although it’s not explicit, I imagine that the Instagram UI defaults to auto-populating locations that less specific when people are uploading images. As a result, I find that I will likely need to account for ways to properly associate images to their proper locations.

Lots of stuff happening and more to come!