Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- QUESTIONS:
- How do you handle difficult clients?
- What do you mean by ‘difficult clients’?
- For those who are adding extra features behind the job description (borders ?):
- I have a rule: before starting working on project I must define the scope of the work and tell to client what will NOT be done.
- If it is not obvious - whether the feature belongs to initial work description or extends the scope - I would always treat the feature request in favour of (?) client.
- For those who have tough communication manners…
- You know - my job is to satisfy client needs no matter if he is pretty and polite or not.
- How do you make yourself stand out from the crowd?
- I’m continuously working on my skills.
- I know that’s not enough, so I’m planning to write a series of blog posts related to my work - i.e. (а именно) iOS app architecture articles.
- Nevertheless, I believe that excellent marks from previous clients are the best indicator. So I’m trying to get more of them as soon as possible.
- I’ve applied to Pro program right after I’ve received first excellent feedback from client. You can see that I’m working as Senior iOS Developer with one client for more than 9 months… And that’s all. I know that is my weak point - I have to get more feedback and more stars. So I’ll try to get more projects and more reviews later this year.
- Why should clients hire you?
- I can deliver excellent solutions on time and under the budget. Also I have strong communications skills and I’m a good team player.
- I’ve graduated from local University in the field of Computer Science with honors, and I’ve been studying strong Math’s and Physics in National Research Nuclear University in Moscow.
- I have a few own projects that makes me some revenue from the AppStore - that is the good indicator showing that I can and prefer to deliver not just software - but profitable solutions.
- TEST ASSIGNMENT COMMENTS:
- I think you are interested in technical details - so I’ll try to explain my work in technical terms.
- First of all, I’ve found the correct ViewController for the assignment. The PhotographersCDTVC had been initially set as starting view controller when I opened the app for the first time.
- CDTVC is an abbreviation for CoreData TableViewController - so PhotosCDTVC was a better choice for the starting point.
- Then I’ve had to get countries from Flickr API.
- FlickrFetcher class was the place where I could get the info about how the data could be obtained.
- So, googling the flickr method flickr.photos.search gave me the info about the Flickr data model.
- A saw that photo JSON dictionary contains place_id. It is clear that making separate request per each photo is not an option - so I’ve found the way (how?) to get the country information using single api call - just add ‘place’ to extras.
- I have to tell that this string is not documented in the flickr.photos.search API documentation - so it is a temporary, but working solution.
- Last word in place attribute gave me the country.
- Making a tableview with sections is trivial with FRC, just adding a sectionName is enough to get it working.
- Note: I do (?) understand that I’ve used not documented API, but for the sake of making a workable solution on (?) limited time I’ve decided to keep it.
- If we do need more info about places - we could add an Entity to Core Data model and get full place information using flickr.places.getInfo method.
- Sorting by author name is trivial - but I want to mention relationshipKeyPathsForPrefetching property of NSFetchRequest. Using it we can avoid fetching whoTook Photographer relationship from faults for every single row of data.
- Creation date can be obtained from extras using date_taken key - adding it to cell is trivial.
- Saving pictures to iOS camera album is also trivial. ALAssetsLibrary were used.
- I’ve used UIAlertView instead of UIAlertController because of deployment target - 7.0. UIAlertViewController is available since 8.0.
- Privacy - Photo Library Usage Description
- For the location and distance.
- The data should have been displayed (why present perfect ?) on the same screen. Evidentially I would have been using separate objects for DataSource. And it would be better to use ViewModel to store distance value.
- I’ve used separate class for DataSource - so it became possible to use same table view with different data sources (first is handled by FRC, and second - by just sorted array of photos).
- I’ve added a transient property to Photo Entity - so did not need ViewModel class.
- Also I want to mention LocationProvider class that tells it’s delegate when the location was updated. Skipping cached locations logic had been added when I was testing it on the simulator.
- Finally:
- Good things:
- I’ve delivered fully working solution on time.
- The only one request is used to obtain data.
- The location provider skips cached locations.
- Bad things:
- I’ve used undocumented extras=place api parameter (перамита) and string manipulation in order (?) to obtain country.
- I’ve used transient “distance” property directly on Entity. The ViewModel would be the better choice (?).
- To be honest, the whole architecture of the app is not the best I’ve ever seen.
- Bad things: placing fetch logic to AppDelegate, CoreData stack in AppDelegate category, using shared FRC code.
- For FRC - I know, it is a common practice, but I would prefer to isolate data access layer from view controllers.
- For CoreData stack - I would better use (?) MagicalRecord (or RestKit).
- For me, if I would implement the whole app from scratch - I would prefer to use VIPER and Layers patterns.
- And, of course, I know that there are a lot of legacy code that must be supported and reused as is. No problem.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement