Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
So I been watching tutorials on iOS development and it seems that every instructor in the video seem to have a good memory for methods in Objective-C which surprises me by the fact that every now and then I am working on a small project and I forget how to call a specific method like to append an NSString or to hide the TabBar from the bottom screen.
An instructor in a video seems to know which method to call whereas I wouldn't even think of calling that same method. For example, when the instructor creates an example iOS app to either leave no spaces in an NSString on a UITextfield, he would use a method that U would forget every often down to even Googling it.
Is it me that my memory isn't great since i am not exposed to methods often or do people study methods in order to fully have them all ready when a certain task should be done?
I feel that my mind isn't fully capable to memorize things like an instructor would with such an ease that it seems he can go by knowing a lot in Obj-C.
How would one get to know more on iOS and be able to memorize method calling without actually having to go to the trouble of trying to memorize them?
Chances are people doing videos have written a script for what they are going to. Including the steps, this is probably why they can recall methods that quickly. It's also something that comes from experience, as you begin to do more and more in Obj-C you will start to learn method names. It's unlikely that most people will memorise ALL of them but that's what the documentation is for + google :-)
Don't worry it'll come. You just need to practice, use xcode autocompletion and built-in doc.
In xcode just hit command + space to get available methods for the leading symbol.
Anyway nobody knows every methods by heart. You'll just end up remembering the ones you use the most.
I would say its impossible to memorize ALL methods, but as you keep coding you keep remembering more and more methods or ways of achieving things. I remember when i was just a beginner and the basic method "removeFromSuperview" was something new to me. In time, you learn much more complicated methods and since you basically use them everyday (if your not copying your code from somewhere) you learn them quite easy. So my answer - in time you can memorize anything but not everything.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
A few days ago I have begun to learn RxSwift and but the more I write code and can't understand which cases need to use reactive programming, I am can write the same code without RxSwift and use NotificaitionCenter, delegate pattern, Grand Central Dispatch, Closures.
I understand that RxSwif and RxCocoa give next opportunity:
There are some different ways to pass information from one object to
another in iOS reactively (Notification, pass in closure, delegate,
KVO, & target/action,) each of these different systems may be simple
by itself but most of the complexity in the logic of an iOS app is in
having to convert from one of these systems to another.
RxSwift/RxCocoa replaces virtually all of these systems with one which
is in a Rx way.
But when I am trying to write code on Rx I saw that this code not easy to understand.
Maybe someone can give examples of when need to use Rx inside the application or maybe in most cases doesn't need to use Rx because code will be complicated to understand, I am enjoyed from knowledge about Rx but not fully understand the good situation when need use it.
Since you are quoting me in your question, I guess I should provide an answer...
The classic example is search... Write a view controller that allows the user to enter text, then makes a network request, then decodes the result into an array of strings, then shows the result in a table view.
In order to do it without Rx, you need to coordinate three methods from two delegates, two closures, and two state variables. Importantly, no where in the code will you see anything that looks even remotely like the sentence above.
This feature implemented using Rx would be a straight line of code going from the search text field to the network request to the decoder to the table view. Just like the requirement description.
So it's not just a matter of needing less code. It's a matter of no longer needing to coordinate desperate kinds of communication systems. It's a matter of having a single chunk of code (or at least fewer chunks of code) to represent a feature.
Well it's a tool like any other. Some people use it because you end up writing less code than you would otherwise. It does have a steep learning curve, but it can be valuable if a project requires it (the project already uses it, and the people involved want to continue using it).
I worked for company that had an RxSwift project. All the architecture was built around RxSwift and all the code had to be written using RxSwift. The code was less complex than it would've been without using RxSwift. The major issue was that it was hard to onboard new developers on the project because as I said before the learning curve for Rx is pretty steep. In the end, for that reason, they decided to start moving away from Rx to a more classical approach.
I also worked for companies that completely reject RxSwift because they don't want another 3rd party dependency in their app.
So at the end of the day it's just a matter of preference. Personally I do see the benefits and conciseness of Rx, but prefer to use as little 3rd party dependencies as possible.
To really get the benefits of Rx you'd have to use it intensely in a project and build your architecture around it. Unlike other 3rd party libraries you can't just put a wrapper around RxSwift in case it goes away and you decide to replace it with something else. But then again Rx is such wide-spread on all platforms and programming languages that I don't think it's going away any time soon.
So long story short, use it and see if you like or not. And if not, at least it's good to know it if you happen to start working on someone else's project that uses it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm starting a massive project for the first time. I was supposed to be one of the developers on this big project, and all of a sudden, the lead developer and his team backed out of the contract. Now I'm left managing this big project myself with a few junior developers under me and I'm trying to get a firm grasp on how this code should be broken up.
Logically, to me, the code should be broken up by the screens it has. I know that might not be how it SHOULD be done. so tell me, how SHOULD it be done? The app has about 6 screens total. It connects to a server, which maintains data about all other instances of the app on other phones. You could think of it as semi-social. it will also use the camera feature in certain parts, and it will definitely use geolocation. probably geofencing. It will obviously need an API to connect to the server. most likely more APIs than just the 1. I cant say much more about it without breaking an NDA.
So again, my question pertains to how the code should be broken up to make it as efficient as possible. Personally, i'll be doing little coding on the project. probably mostly code reviews, unit testing and planning. Should it have 1 file per screen, and parts that are repeated should have their own classes? should it be MVC? We're talking a 30k line app here, at its best and most efficient. is there a better way to break the code apart than the ways I've listed?
I guess my real question is, does anybody have good suggestions for books that would address my current issue? code clean was suggested, that's a good start. I've already read the mythical man month and code complete but they don't really address my current issue. i need suggestions for books that will help me learn how to structure and plan the creation of large code bases
As I'm sure you know this is a pretty vague question you could write a book answering it. In fact, I would recommend you read one, like Clean Code. But I'll take a stab at a 10,000 foot level overview.
First if you are doing an iPhone app, you will want to use MVC because that is how Apple has setup their frame work. That means each screen will have (at least) a view-controller, possibly a custom view or NIB.
In addition you will want your view controllers pointing to your model (your business objects) and not the other way around. These objects should implement the use cases without any user interface logic. That is what your view-controller and view will be doing.
How do you break apart your use cases? Well, that's highly specific to your program and I won't be able to tell you with a (lot of) details. There isn't a single right answer. But in general you want to isolate each object from other objects as much as possible. If ever object reference ever other object, then you don't really have an OO design, you have a mess. Especially when you are talking about unit tests and TDD. If when you test one part you end up pulling in the whole system, then you are not testing just one small unit, are you?
Really though, get a good book about OO design. It's a large subject that nobody will be able to explain in a SO answer. I think Clean Code is a good start, maybe other people will have other suggestions?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I can think of quite a few components that need to be created when authoring a web application. I know it should probably be done incrementally, but I'd like to see what order you usually tackle these tasks in. Layout your usual order of events and some justification.
A few possible components or sections I've thought of:
Stories (i.e. pivotaltracker.com)
Integration tests (Rspec, Cucumber, ...)
Functional tests
Unit Tests
Controllers
Views
Javascript functionality
...
The question is, do you do everything piecemeal? (one story, one integration test, get it passing, move onto the next one, ...) OR complete all of one component first then move onto the next.
I'm a BDDer, so I tend to do outside-in. At a high level that means establishing the project vision first (you'd be amazed how few companies actually do this), identifying other stakeholders and their goals (legal, architecture, etc.) then breaking things down into feature sets, features and stories. A story is the smallest usable piece of code on which we can get feedback, and it may be associated with one or more scenarios. This is what Chris Matts calls "feature injection" - creating features because they are needed to support stakeholder goals and the project vision. I wrote an article about this a while back. I justify this because regardless of how good or well-tested your code is, it won't matter if it's the wrong code in the first place.
Once we have the story and scenarios, I tend to write the UI first, followed by the classes which support it. I wrote a blog post about a real-life example here - we were programming in Java so you might have to do things a bit differently with Rails, but the principles remain. I tend to start writing unit tests when there's actually behaviour to describe - that is, a class behaves differently depending on its context, on what has already happened before. Normally the first class will indeed be the controller, which I tend to populate with static data just to get the UI into shape. I'll write the first unit tests to help me get rid of that static data.
Doing the UI first lets me get feedback from stakeholders early, since it's the UI that the users will be interacting with. I then start with the "happy path" - the thing which lets the users do the most valuable thing - followed by the exceptional cases, validation, etc.
Then I do my best to persuade my PM to let us release our code early, because it's only when the users actually get hold of it to play with that you find out what you really did wrong.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Ok, so you've got an idea for a potentially successful online start-up. You know that you'll never set the thing up yourself, you prefer the stability of your permanent job. Then you think, "Hey maybe my boss would be interested in backing this as an internal project. Obviously I'd want X% of the profits for coming up with the concept in the first place and I want to be able to retire when we get bought by BigCorp."
Can you follow any legal procedures to prevent anybody you tell about a business idea from exploiting it independently?
What kind of deal should you be looking at (e.g. profit share, shares etc)?
IANAL, but I've been around the block a few times.
First, find a competent attorney that specializes in startups and get some professional advice and follow it. Preventive lawyering is really a whole lot cheaper than waiting until it is too late.
Second, protect yourself and make sure you do everything in writing. If your employer doesn't bite and you decide to do it yourself then you'll be protected when you're successful and your company comes back later and tries to claim ownership over the idea. I've seen this happen more than once.
Third, try to get the people you pitch to to sign a non-disclosure. If they have half a brain they won't sign one, but it's an important sign of your intent. Without an NDA do your best to not pitch your idea to anyone who can take the idea and run with it based on your elevator pitch. That generally means really competent technical people, or an expert in the business area.
If you get to the point of having to worry about a deal go back to that competent attorney you retained.
To answer your first question: no. There's nothing you can do that will stop someone from exploiting an idea you have. Apart from patenting it. (Which you aren't really supoposed to be able to do unless you've already at least partly implemented it in the first place).
My advice would be: if you know someone you trust not to steal your idea, tell them. If not, don't.
Also, if you have an idea and you tell your boss, you're not really entitled to anything in terms of ownership of X% of profits. That's just supposed to be part of your job.
Sorry: this probably seems like a negative answer, but I'm trying to be realistic.
Ben
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
G'day,
While having a think about this question here about overdesigning for possible future changes it got me thinking.
What reasons against can you provide to people who insist on blowing out designs because "they might want to use it somewhere else at some stage in the future"?
Similarly, what do you do when people take the requirements and then come back with a bloated design with lots of extra "bells and whistles" that you didn't ask for?
I can understand extending a design when you know it makes sense for requirements or possible uses that exist either right now or in the near future. And I'm not advocating just blithely accepting a list of requirements and implementing that explicitly without providing any feedback on what you think may be missing.
I am talking about what to do when people insist on adding, or having, extraneous functionality so that "we might use it somewhere else at some stage in the future?"
Plenty of good reasons on Wikipedia.
http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It
The time spent is taken from adding, testing or improving necessary
functionality.
The new features must be debugged, documented, and supported.
Any new feature imposes constraints on what can be done in the future, so
an unnecessary feature now may prevent
implementing a necessary feature
later.
Until the feature is actually needed, it is difficult to fully
define what it should do and to test
it. If the new feature is not properly
defined and tested, it may not work
right, even if it eventually is
needed.
It leads to code bloat; the software becomes larger and more
complicated.
Unless there are specifications and some kind of revision control, the
feature may not be known to
programmers who could make use of it.
Adding the new feature may suggest other new features. If these new
features are implemented as well, this
may result in a snowball effect
towards creeping featurism.
See also: http://en.wikipedia.org/wiki/KISS_principle
Especially on an embedded device, size is money (larger Flash part, say, which costs more and has a longer programming time at manufacture; or more peripheral components).
Even on a Windows application, the larger your application and the more features it has, the more it costs to develop; wait until you know what's needed and what's not and you'll waste far less money developing stuff that turns out not to be what was needed at all.
Also, any additional functionality brings with it the potential for bugs.
It's good to think properly about the requirements before developing something, but over-designing is often just borrowing trouble.
Them: "We might use it somewhere else at some stage in the future."
Me: "Yes, we might. And we might not. And we can't know, now, in what ways we might want to. And if we do want it at some stage in the future - that's the time when we'll know the ways in which we want it. That's when we can write it with confidence. On the other hand, if we write it today, but never need it, we've wasted resources to develop something we didn't need. And we've added to our code bloat, so it's harder to find the pieces of our code base that are in use, because we've got all this (presently) unnecessary code crowding out the useful stuff."
In our team we just say "YAGNI". It reminds people why. There is MORE than enough stuff on the web about YAGNI if you think you need to collate it to provide a report.
Actually, having someone say "YAGNI" to you on our team cuts a little because it's like saying "C'mon; you know better than that", which always hurts a little. :)
It's a balance, as a rule I over design only where it's cheap to do so. For instance, I wouldn't write a function that takes in 2 parameters and adds them, instead I'd write a function that takes n-parameters and adds them. However, I don't write a function that takes n-parameters and adds them using assembly.
You say
I can understand extending a design when you know it makes sense for requirements or possible uses that exist either right now or in the near future.
and I guess that sometimes people see this line as blurry something that "makes sense" to you may be over-design to someone else.
Overdesign (solving a problem in a way that is more generic than needed) a specific piece of architecture is acceptable only if you can afford it.
If you accept extraneous functionality (which is generally speaking different from overdesign) you need - again - to accept the costs that come with it (time ==> money) - if you can't afford those extra costs then you got your answer :)
There's a big difference in providing for future functionality and adding future functionality. A good design should have the "hooks" or whatever to provide for new features or modifications.
There are two ways that you can possibly handle this situation. The first way is that if they are contractors and providing the software to you. You can simply refuse to pay for all of the extra functionality and impose very strict deadlines for your required functionality. If they miss the deadline then you impose financial penalties for every day they are late.
The other way is if they actually work for you. If this is the case then you can get rid of them or downgrade them in their performance reviews.