Nikon FM, 50mm F1.8, Ilford HP5+@1600
Nikon FM, 50mm F1.8, Ilford HP5+@1600
Nikon FM, 50mm F1.8, Ilford HP5+@1600
I wonder what the minimum order would be for a custom Blackwing.
The moment when you realise you basically have 9/10 of a CMS and should just complete it.
My little girl is going in for surgery today.
I hate SD cards. There is nothing I like about them. There are a million different models from the same company with some minor differences and it takes forever to find the best deal.
There is however one thing that I hate more than anything else about SD cards, and that is that flimsy "lock" button. What it does is to either allow or disallow writing to it. It is something I assume are coming from the floppies. Back then it had a purpose, because you don't want to write over some hilariously expensive software by accident. These days they are just an annoying thing from the past. The reason I hate them is that they break, and then you can't write to your SD card. I really hope that the thing we start using after SD cards don't have them.
Unless you shoot a lot of sports, video or have a camera with really big files I don't think the write speeds matter that much. But your milage may vary.
I buy the cheapest possible SD cards I can find. Here is my process, I go into where I usually buy photo gear and I navigate to the memory cards section. And then I order by price. Then I start looking for the two in one packs. They are usually cheaper. And then I include the cheapest 16GB and the cheapest 32GB card for reference.
Then I take the price and divide it by the total number of GB, and I buy the cheapest one.
I have used really expensive cards and I have used cheap ones. And I don't notice any difference in how long they last. There are some difference in write speeds, but that depends on the camera. But the difference is not large enough to matter, for me.
If you worry about them failing on you: get a camera with dual SD slots and "mirror write" (it writes the same image to both).
My system for dealing with SD cards is that I always make sure that I have enough SD cards to shoot for a whole weekend without having to import them into my computer. And I replace them as soon as I notice it takes a long time to import the files. Because when read speeds start to take a long time I know it will fail soon. So I break it in two and throw it in the garbage. Just to make sure that if someone thought I threw it out by a mistake – don't take it back out of the junk.
When I order something else I always throw in at least two cards or a two pack of cards. You can never have too many of them. The best price at the moment is either 16GB or 32GB, but it varies. When I look now it is the cheapest for 2x 16GB, but that's just because the 32GB one is out of stock.
Here is the thing I don't get. Why does a 1x16GB / 1x32GB and the exact same just with two cards cost the same?
The hats from a handmaid's tale would be the perfect "leave me alone" hat for when I'm traveling or sitting somewhere public
I have written about this lens before, but I don't recommend it, even though I love it.
A 8mm or a 12mm equivalent is very wide. It have a field of view of 180 degrees. That means that it captures as much as possible before the images starts getting round. If you look at a lens and look where the lens "body" lens, this is where the field starts on a 8mm.
It is great for when you just want to capture the whole room or scene, and for when you have a lot of straight lines to play around with. The biggest challenge with the lens is to find interesting stuff to fill the frame with
I fucking love the remake of The Jungle Book
I love writing with this pencil, but I'm definitely going for the Blackwing 602 the next time. Even though the regular one looks so much cooler.
What's a snow day?
I assume pencil sharpeners is a rabbit hole within my horizon
Got my soft blackwings. First time I've paid for pencils. So, what's the recommended way to carry pencils?
I don't need a 56mm f1.2 I don't need a 56mm I don't need a 56mm
I think I'm going to add a context to my micropub server called "facepalm-of"
I own both the 35mm f2 and the 50mm f2 for my X-Pro 2, and I plan on buying the 23mm as well as a zoom, probably the 18-135.
The reasons I want both fast primes to cover some of the more commonly used focal lengths is about convenience. I love having a fast enough zoom, with a wide range when traveling or attending family stuff. The 18-135 seems like the best option in the current Fuji lineup because I most of them either start to long or stop too short. I actually love getting full frame 24-70 zooms and putting them on crop cameras for this reason. You get something like a 38-112 (on Canon). Everything from a little bit wide to a excellent portrait lens.
Back to the 18-135. It is not the fastest, but it has a excellent optical image stabilisation system, which more than makes up for the slower aperture on it.
The reason I want to have fast primes to cover some of the more common focal lengths is because they are faster and much lighter. A 23mm is a excellent walking around lens, and for family stuff because you can capture whole groups without having to step too far away. I love the 35mm for my "default" lens because it is great for shooting more or less everything, without being too long for portraits (something I think the 23mm is). And I love the 50mm for shooting portraits.
Fuji often have faster versions of their F2 lenses, like the 56 f1.2 and there are 1.2 or 1.4 versions of the 23 and 35. But I think the F2 lenses are better, at least for me. Because they are lighter, fast enough, and the lower weight means, less glass, which means faster auto focus.
The zoom on the other hand is something I want to use when I know that I will use many different focal lengths, for example while traveling or a family gatherings. Or when I want to get closer without moving: in other words family stuff.
I could go for the 16-55 f2.8, but I think it ends a little bit too short, and all the zooms that start at 50 start a little bit too long to make sense. That leaves me with the 18-135. It looks like a great compromise between versatility and weight. A f2.8 version of it would be way too heavy and expensive.
@hjertnes testing mentions
Finally another season of Jessica Jones.
tp2org I put together a simple taskpaper to org script, because I prefer writing in taskpaper, while I prefer org mode as a task management solution.
@eli What's the best micropub clients?
Added support for replies and likes last night.
I guess I'm looking at it differently when I say GitHub is great when we are hiring compared this this guy.
I ignore the social media aspects, and look for source code that can give me an insight into how good the candidate is.
When I spent weeks upon weeks to write about React I said that no one should use the context api because it was likely to break in the future, that time is coming. There is a new version of the context api on it's way into react. Look here for details on how to use it.
The short version is that the new context API will be more like a component, that you either use as a "Provider" or as a "Consumer". Again, look in the blog post above for details.
It looks like it will be a million times easier to understand and use compared to the old system.
Oldpub is tailored to make it possible to use MarsEdit with static site generators like Hugo, and Micropub is a Micropub server for generators like Hugo.
The former is done as far as I'm concerned. It pretends to be Wordpress. Micropub on the other hand is something I intend to put more work into, and to make it a full featured micropub server.
Both are written in Python 3 and Flask.
I'm going to give Safari a try as my default browser for a while. Chrome is a little bit weird at the moment, Firefox is fine, but the memory usage is ridiculous and it looks like shit.
I hit my daily Move goal for the 365th time on my #AppleWatch.
Imagine that Excel itself was implemented in its macro langauge: that is the power of Emacs.
What are the programming languages I’m interested in, or are using in 2018.
Python, Node and C# are my go to languages when I’m going to write a backend. What I’m going with depends on a number of factors. But I mostly go with Python and Django for personal stuff, because I know it so well and I think it is a lot of fun to work with. I often go with Node if I’m going to write something small and single purpose, because of how small and fast it is. And I think C# and .NET Core is a great option when you want the safety of a strong type system.
For basic scripting my go to tools bare shell scripting and Python. I use plain shell scripting when I just want to build an abstraction for some complex commands or series of commands, and I got with Python for anything more complex.
I’m digging more and more into Swift as I’m getting serious about native App Development again. I like it a lot. And I enjoy it way more than I ever did with Objective-C. The strong type system makes it a lot easier to catch stuff under development time. But I’m not a huge fan of Xcode.
Knowing how to use plain SQL is the smartest thing I ever did. It was the second real programming thing I learnt, after PHP. It is a fantastic tool to have in your tool belt for when you need to run plain sql to fix stuff, read stuff straight out of the database or to clean stuff up. Or even if you don’t want to introduce a ORM to your project.
LISP. I have developed a real interest in LISP and Scheme over the last year and a half. And I love how elegant and fun it is. I use it all the time to extend Emacs / Spacemacs.
What are the languages I’m going to look into in 2018:
ReasonML. I’m going to play around with this on some small front end projects. And I might introduce it at work if I like what I see.
LISP. I’m probably going to play a lot more with emacs lisp and chicken scheme. Because the elegance is too much fun
If I find the time I’m also going to take a look at GoLang
As we move into this more and more divided world, where the moderate gets more and more ignored, and not just in politics I think we are missing something.
I see a lot of people ignoring a simple details. And they are not dumb, just a little bit let's say "unreflected".
People do things because they have reasons for doing them. As their horizon of understanding changes they chose differently than they used to.
This is the reason politicians and other leaders don't do what they said when they tried to get elected.
You don't need to agree with the choices, or the reasons for doing something. But keep in mind that most people have reasons they do what they do. And very rarely they do something just to be evil or terrible.
Editing files with Emacs and Tramp over SSH is freaking awesome. Where have this been my whole life?
I fucking hate working form home when there are other people here.
I've changed the Overcast playback settings back to 1x, after using the max playback speeds for years.
Why? I'm trying to be more intentional on what I do and how I do it this year.
Awesome Clojure book I've been reading for the last few days : Clojure for the brave and true
When you choose what programming languages to use for your project you should take in to consideration if developer productivity or reliability is more important.
For example if I develop the backend in Python and Django I’m much more productive, but if I use a programming language such as Java or C# I get a much stronger type system, which are catching more potential problems during compile time (if you are using it correct).
Having a strong type system can help you a lot, which means that it helps you to make sure that you don’t add a number to a string variable. But that means that you need to use more time declaring what type a variable has. But on the other side you often have to add more code to make sure that your data structures have the correct content in dynamic languages like Python.
And having a strong type system is also very helpful when you refactor code.
On the other hand, languages like Python often requires far less code than C# does.
It doesn’t matter that much on the end result, but my experience is that having solid automated tests are very important when you use dynamic languages. And I think there are something very comforting about letting the compiler doing the first round of validation.
This is by the way one of the big advantages of using Swift instead of Objective C.
I have a longer and complicated relationship with exceptions, and I do in general think that they are the right solution, but I’m not a fan of the syntax. And I also think that they are not always the best solution. For example I personally think that to throw an exception when you are trying to fetch something(as in one exact row) from a database and don’t get anything back, I would prefer null instead of an exception because it ends up being a lot of code to deal with something very trivial. But when there are actual problems (like you try to get one of something and there are many, then you should get one). Long story short.
You have many different approaches when it comes to dealing with Exceptions. There are problems you can recover from and then you have those you either can’t recover from or those you don’t know about. I say use a specific solution to fix the former. But I often use generic ones when it comes to dealing with “the rest”.
I have written many versions of the higher order function below over the years. It is a simple HOF to wrap a function that will or might trigger an exception in a try catch and deal with it. For me it almost always means sending some feedback to the user and reporting the error.
To implement tests in a Web App requires your to test three different things: the backend, the front end and cross browser testing.
Assuming your backend is a series of REST API’s, the tests should make sure that your API’s are always doing what you expect even when you get input you don’t expect. And it is always a good idea to implement tests that re-produce bugs that are reported to make sure they don’t are re-introduced.
Then you also need to test your front end code. This means that you test all of your components or views and make sure that they always do what you expect, even with input you don’t expect. This is especially important when you are dealing with forms.
And last you should also use something like Browser Stack to do cross browser testing. Just to make sure there aren’t any problems with either your backend or frontend code in any of the browsers you support.
The reason you want all of this is to make sure that a) everything works right now b) test if some changes you made broke something c) see if performance improvements actually improved things.
Web Development is in a weird place for me at the moment. The choices for front end development are pretty solid. Frameworks or libraries like React, Vue, Ember and Angular are pretty solid; I personally prefer React, but all of them are good. Backend development on the other hand is in a weird place for me. I have used both Django and .NET a lot in the past. But neither of them are what I want in 2018 or 2017 for that matter.
The good thing about Django is that everything is easy to do and you get all the tools you need to build a database driven, fully tested RESTful JSON API out of the box. And you get the same with .NET Core. What I don't like about both of them is that there are a little bit too much "magic" in other words stuff that the frameworks just does. The thing I don't like about Django or Python is the lack of a solid type system, which makes the tests more verbose than needed and too much validation code. And C# and .NET have gone a long way, but there are still too many places where you need to define full classes to do simple things.
I spent a lot of time last year to see if Node + Express was what I wanted. And the answer is not quite. The reason is that I could come up with a setup that is almost there, but the type system is still too far away from what I want.
The next thing I started to check out was F#, Chicken Scheme and Guile. But none of them had all the stuff I wanted.
What I want is either a framework or a set of libraries I can configure to Database Migrations, define database tables in code (ORM), write RESTful API's, manage authentication etc. And I want the language to have a good type system, support functional programming well and most important be fun to use.
The thing I mean when I say "good type system" is to define what kind of parameters to I expect to get of what type over URL parameters, GET Parameters and BODY data. Ideally those who are required and not required.
What I have decided to use for now is Clojure. It is a LISP, which I love. And I think everything is just a question of setting everything up to work like I want to. My "starter" project is on GitHub but it is far from done.
The "How do I get into programming?" questions is one of the hardest things to answer. Or I do at least think it is. This is because being good at programming is about having experience doing it and having the drive to always looking for better ways of doing everything. Including those things you didn't know was a problem, and of course the things you think are annoying.
The way I got into programming, and the way everyone I know who know how to code got into it was by doing. They had something they wanted to make, and they figured out how to do it. I started with web development. First I wanted to add a visit counter to my web sites, then I figured out how to make it only count unique visitors within a timeframe. Before I moved on to implementing a full CMS driven by PHP and MySQL.
How you learn the basics are up to you. Some people like to watch video lessons, while others like a more interactive approach and I prefer books and blog posts. How you do it is up to you, but I would encourage you to try different methods and stick with what works for you.
And the final step to get started is to find a project. If you are doing a web development, making a custom CMS is a good place to start. Not because you'll get the most amazing thing every. But just because you will learn a lot from doing it. Everything from server side rendering on what people will see and more advanced Web App development on the admin side of it.
A todo app is a good place to start, if you are doing an native app; but also works if you are doing a web app.
Then I would encourage you to make what every you are making as good as you have the time for. And always improve everything as you learn new stuff. A solid project that shows how you work and what you can do is always useful when you are going to apply for a job.
There will be a lot of "abstractions" no matter what kind of software development you get into. They are a way to make more complicated or time consuming tasks easier to work with. The good thing about them is that you don't need to know all the details when you start out. The bad thing is that you need to learn more things. But I would still take the time to learn to theory behind them as you get more experience.
If you decide that you would like to make a living as a developer then I would start by looking at what kind of languages, frameworks and technology are popular in your area. And the best way to do that is by looking a job listings. And then start learning that. The next step is to have some code you can share with potential employers when you apply for a job. The closer the code is to what they use the better it is. It is just a way to show them that you actually know how to do the job. Because the biggest nightmare when we hire is to get someone who don't know how to code.
I've been looking for a good replacement for Django for a while. What I like about Django is that you get everything you need to build a database backed backend out of the box. What I don't like is how bad of a fit Python is for functional programming, and because the type system isn't that great.
Clojure seems like the best option I've tested out this far.
There was a lot of talk about the merging of iOS and Mac OS at the end of last year. And I never wrote anything about it, because I never made up my mind what to say about it.
When people start to talk about a single Apple OS, I assume they are talking about making them more similar under the hood. Because I know I don't want OS X on my iPhone, and I certainly don't want iOS on my MacBook.
I'm certain that there is a "Core" that is maintained separately from OS X, iOS, TV OS, Watch OS etc. And that is the "Apple OS" everything Apple makes with Apps shares. And I think that Apple will, and I also think that it is in their interest to limit the differences between the platform as much as possible. One of them is to make sure that the API's on their platforms are the same, except for where there are really good reasons for doing so.
If expanding from iOS to OS X would be more like adding an extra Storyboard to the Xcode project, I assume that it would be more of an option to add OS X to the supported platforms. This would solve many problems that both Apple and third party developers have. It is hard to maintain many different projects at once. And by limiting the number of them, and making them as similar as possible, without turning Y into X or X into Y, you could end up with more Mac Apps. And more Mac Apps adding support for iOS. For example the app I'm writing this blog post into (MarsEdit).
I think the biggest issue with maintaining both iOS and Mac OS at this point is that even the most trivial stuff like a fucking colour is not the same across the different platforms. Making Apple's development platforms more modern is a story for another day.
Let’s say you are building a new web app. When should you start to optimise it?
I personally think that starting to make sure something is as fast as possible is the last thing you should do. Because there are a number of things you should think about and test out before you start on that.
First, you need to make sure that what you made are doing what you want it do to.
Second, make sure that what you made are needed and add value to your product.
Third, make sure all the user experience is how you want it to be, so that your target users will actually use it.
Then I would start to make sure everything is as fast as possible. This means everything from how fast your code is to how large the code the browser have to load is. My approach to optimising have always been to find the way to do something that requires the least work. For example by limiting how often you commit queries to the database(saving data), using the fastest possible queries to fetch data and, if you are looping over data: always continue to the next row as fast as possible when there is no point in running a lot of extra code.
If you’re still not happy with the performance I would start to debug and identify the parts of your code that is slow and try to find better ways to do that.
In the backend it’s often about optimising how you deal with the database and to cache slow stuff in memory (redid) and on the front end is it often about using many smaller methods instead of large ones and to limit how often stuff are re-rendered.
Decided to pretend like I'm a designer and write some styling for my micro blog last night.
I have been trying to get into meditation for a very long time. I think some of my first attempts where back in 2009. It have been difficult to identify what is important and not. And I gave up after reading countless books. The "breathing" app on my Apple Watch got me back into it, and I used the Oak app for a while. Before I started to use Headspace a few days ago. It is awesome. And I would encourage anyone that want to get into it to check it out.
Three things I want from a future X-Pro 3:
In body stabilisation.
Gnu Artanis. A Web Framework for Guile (the GNU Scheme implementation).
I shoot both film and digital. And I use them for very different reasons.
When I want to make sure that I end up with some good images I always bring my X-Pro 2. I can shoot duplicates and make sure that I at least have some good images at the end of the day. No matter how the lighting conditions are. But I often bring my 35mm camera instead if I just want to shoot for fun.
If you go for a film camera you can more or less anything. I personally prefer very manual cameras, but you can also get something that are more like a modern DSLR or a point and shoot. The reason I prefer manual cameras is that they just work, even without a battery. And you just expose and shoot. This process is a very useful to really understand how light and the different settings on your camera works together.
The reason people shoot film vary. Some do it because they like the process, others like the simplicity and some because of the look of the films they use.
I shoot film because I enjoy having some stuff in my life that don't require me to re-charge the batteries all the fucking time. And I really enjoy how the images look. Good black and white film looks much better than anything I have ever gotten out of a digital camera. And I really love how goofy Fuji Superia colour film look. Some do it with filters, I personally prefer to go back to where the Instagram filters or Lightroom Presets go their looks from in the first place.
Dear designers: can you please stop hiding the fucking sign-in button.
Testing out Firefox, for the first time since the Chrome Mac Beta. It's fast, but damn it is ugly.
There are pro’s and con’s to both approaches, and there are times when one is better than the other.
If you are developing something where the content is in focus, in other words where the user of your web site are primarily consuming the content like for example a blog then doing more of the work server side is the better approach. Because it will load faster and less resources have to be transferred to the client.
But, if you are developing something where there either is a combo or where user interaction is the primary thing. What we call a web app. For example Gmail, Facebook or Twitter, then doing more on the browser is better. This is because it enables us to do more advanced functionality that in the past was reserved for native apps.
Just because a modern framework is there, doesn’t mean it is the right thing for everything. Or for all parts of what you are building
Hot tramp, I love you so! 🎵👩🎤
This is too much fun: KD Pro Disposable Camera
I decided to finally do the inevitable after I got out of the hospital: migrating all of my sites over to Hugo. There are many good reasons for using WordPress, and it is a reason for 30% of the web or something crazy like that runs on it. But it felt like I only used it because it worked with MarsEdit.
Hugo is like Jekyll and Pelican a Static Website Generator. This means that you build all the resources and upload them instead of generating output based on requests.
There are good and bad sides to both. The Hugo approach is less dynamic, while the latter is more dynamic. Some people want or need that dynamic nature of a database driven CMS like WordPress. While others like me are more than happy with something a little bit simpler.
But I'm cheating. Because I have added two servers or backends to my Hugo sites. Or some of them. To enable posting from apps.
I love posting from the Micro.blog apps on both OS X and iOS, which lead me to implementing a simple MicroPub server for it. And I love using MarsEdit, and that lead me to starting to implement a WordPress XML-RPC compliant API for Hugo (or anything like it).
The reason I went with Hugo over Jekyll or Pelican is simple:
I hate Ruby with passion
I enjoy Python, but for some reason don't like Pelican.
Hugo is written in Go and is ridiculously fast.
Hugo supports scheduling posts (which was one of the reasons I dumped Jekyll the last time, and because it was slow).
I'm enjoying using Hugo this far. The awesome thing about Hugo is that it is really easy to make tools that make stuff easier, because you are just dealing with files. And page loads are very fast. The best thing however is not having to deal with WordPress updates.
The next thing is to start looking into making my own templates for some of my sites. And to complete my XML-RPC server.
Is it better than WordPress? For some people. But I didn't start to enjoy using Hugo before I got up a proper XML-RPC server so that I could use it with MarsEdit.
GoDaddy is a weird thing to call your company.
Oldpub. I just completed the first “working" version of my Wordpress XML-RPC server. It is far from perfect, and far from complete. But it works with MarsEdit for plain text posts.
Working on a Wordpress XML-RPC compatible server that you can use with Hugo etc.
Just deleted Spark from my phone.
The street sign right outside my house aka my favourite bokeh testing spot. Shot with my Nikon FM, E-Series 50mm F/1.8 with Ilford HP5+ pushed to 800.
Luna. Shot with my Nikon FM, E-Series 50mm F/1.8 with Ilford HP5+ pushed to 800.
This one is awesome.
Let’s say you have a object, and you want to loop over the keys and values of it. There is a new method on the Object prototype for this. Just run Object.entries and you’ll get a list of list
I wonder how much code could be removed with all the recent additions to the Object prototype?
The single thing I hate reading in support communication (especially if it's a open source project) the most: read the documentation.
Hugo is pretty awesome. I really love that I don't have to make up any weird hacks to make scheduling work.
First day back at work. This might be the time to get back into standing at my desk, because it is more comfortable to stand than to sit.
I don’t think there are much “right” and “wrong” when it comes to focal lengths for shooting street. Because it all depends on your personal taste and what kind of pictures you want make.
But the standard focal lengths for street are (on a 35mm / full frame) 28mm, 35mm and 50mm. And something close to a 85mm is popular for street portraits.
The creepiness is relative to the focal length. And I personally think that zoom lenses with a very long range is kind of “not cool”. But I don’t think something like a 10-24 or a 24-70 is a problem from a creepiness perspective.
But there are few things I think is important when you are picking a lens to use in street photography. Don’t get me wrong, you can use anything.
I would get a small and light prime, with fast auto focus. Because stuff happens fast, and lenses that use a long time to focus or fiddle with zooming is the kind of thing that could cause you to loose a lot of shots.
You want fast auto focus, because good pictures come and go faster than you can shoot most of the time. The lens should be light and small because it is a pain in the ass to walk around with a huge lens for a long periods, and people notice huge lenses way more than a small prime.
A manual lens with a focus scale is also a good option. This means a lens where you see meters and feet on the focusing ring. When I do street shooting with my Nikon FM, I usually focus to a certain distance and work accordingly. Then you only walk around and change the shutter speed.
My personal preference on Fuji systems is to use their line of F2 lenses. Because they are small, great quality and have fast auto focus. I usually set them to F8, when there is enough light, and then step down whole steps until I have a combo that works.
The slowest shutter speed you can use, depends on many different things. It depends on if you have any kind of image stabilisation in your camera or lens. And it depends on how steady your hands are. But also on the camera. For example, analog or up to around 16 mega pixels, no problem using a 1/60th of a second. But I try to not go under 1/100th on my X-Pro 2 with a 24MP sensor, because I takes way less to have a blurry picture.
More pixels aren’t always better.
They are finally supported now.
Stephen Fry has cancer. This hurts.
Finally. I'm quite close to being happy with the Hugo setup.
I just came over this very useful method on the Object prototype. I’m not sure if it is a ES7 or 8 thing. But if you want all the values from a object, you can use the Object.values method. It will return just the values.
One of my favourite things Microsoft have made in the last few years is the OmniSharp Server.
The key to being happy about coding in languages like Java and C# is a excellent auto complete engine. And this is what the OmniSharp Server is. One of the reasons .NET have become so popular is that Visual Studio is so good, and the best part of it is the Intellisense engine.
The OmniSharp server is a server or service that other IDE´s and text editors can use to integrate C# and F# auto complete. It is what Visual Studio Code uses, and I have also added it to my Emacs / Spacemacs setup.
It is a brilliant move. And I believe stuff like the OmniSharp server is the future of good software development tools. Every editor shouldn’t have to implement the same thing. It should be just a shared server that all of them can hook into.
@manton Have you documented on how to get the image uploading / posting from the official apps to work with a micropub server?
I can't see any requests getting through to my server, only a error saying "Photo URL was blank".