I have recently started learning cocoa development with a fairly large scale(probably Core Data based) application in mind as my goal. I have been looking into development methodologies that would be used to help build a higher quality product with better code and although I have found a couple that I am sure I would like to use, such as version control(probably with git) there are some others like unit testing that seem like they would be hard to use when the majority of the application is written with IB and Core Data. I would really appreciate some suggestions as to what tools or workflow methods a solo developer should be using.
Thanks.
P.S. First post in SO!
EDIT: By the way I primarily plan to develop for OS X and not the iPhone.
welcome to SO :-)
One thing I struggle with as a solo dev is discipline...!
Always comment, test, design ahead if you want to increase the quality of your code, reduce the amount of times you re-write something until your interfaces/class structure actually works, and have code that you can come back to in a years time and know what you mean!
Apple have a great guide for Unit Testing
As of iOS 4, Apple have added a UIAutomation framework for testing the User Interface of apps.
O'Reilly has a guide here, and you may want to have a peak at Apple's official documentation for UIAutomation
Its fairly new, but it won't hurt to take a look at it.
There has also been a query on SO about automated testing of iPhone apps.
Our own Chris Hanson did a series of posts about Cocoa and Unit Testing. It isn't as difficult as you think.
use git, it makes it really easy to go back to prior versions
comment your code, as others mentioned you'll need to look at it years later and understand it
get in the habit of building yourself reusable classes. Many tasks you perform when developing will need to be duplicated in other projects
expect that no matter how diligent your try to be, your users will have problems. As such you have to develop a methodology of allowing your customers to report their errors to you that is useful. I recently implemented this for myself. It's basically a way to get meaningful stack traces back from users through email. I learned this here.
Related
all.
So, I'm completely new to programming, especially mobile development. Considering goals for a future app I'm designing, I've been thinking of using NativeScript. I was reading the book "The NativeScript Book" offered on NativeScript.org, and they were discussiong JIT vs pre-compiling (AOT I guess it is? Correct me if I'm wrong on that). They also showed how a framework like Xamarin compiles down to the native file (.apk for Android and .ipa for Apple) where NativeScript runs in a javascript virtual machine.
When reading this, it seems like code that has been compiled BEFORE and not just at the time of execution would have a significant advantage in terms of speed, especially on phones where they aren't nearly as capable as modern desktop computers.
Can someone address this concern for me? Likely it's because I am ignorant and don't understand things yet, so please enlighten me and help me learn.
THanks :)
If you are new to programming, the performance of the framework should not be one of your priorities. You should start by focusing on other aspects, like portability, or simplicity of the solution. Learning to write good software should be your top priority instead of trying to write fast software.
Nonetheless, if this is really important for you, there are some benchmarks available opposing the different mobile oriented frameworks. For instance, the NativeScript website has one :
https://www.nativescript.org/blog/nativescript-and-xamarin
Check the 'Speed' section. It states for instance :
In these tests, you can see that Xamarin is roughly 200 ms faster than NativeScript at startup time.
But as you'll notice that when comparing performances, benchmarks always target only one aspect of the solution. This one in particular targets boot time. Some others target sorting of large arrays, or HTTP requests speed.
It is impossible to get a global performance test indicating which solution is the best. I think that one good example in that regard is the comparison of Xamarin VS Native languages (Swift // Java). Check this page :
https://www.altexsoft.com/blog/engineering/performance-comparison-xamarin-forms-xamarin-ios-xamarin-android-vs-android-and-ios-native-applications/
Xamarin is close to native solutions since it uses the native SDKs, but you will notice big differences between Xamarin and native. So it would be event more complicated to compare Xamarin and NativeScript which has a completely different logic !
In my opinion, you should start by the framework you like the most. And change it based on your experiences if you are not satisfied with it.
I was wondering if you guys know of any software that allows me to jot down notes in a project based environment, as well as enabling me to track bugs or other issues in OSX. Basically, I have a lot of little projects on the go, and I would like to have one place where I can store and organize all their information. I have done lots of research on issue tracking systems, but they all seem to be overkill for what I need. I essentially need just a single user desktop application were I can enter bugs for myself to view later. So far I have basically been doing this with sticky notes/other such applications, but I think its time for a step up to an application that stores the history of bug fixes, open issues, etc. Any ideas? Thanks beforehand!
I know you mentioned desktop, but from reading your question I would recommend Trello http://www.trello.com.
Trello is really nice for keeping track of small to medium projects and does not take up all of your time when entering in steps.
I'm a freelance web developer working on multiple projects. Earlier I used to use small applications to keep track of project tasks. Now that the number of projects have increased, I've been using Microsoft Project Professional. The project management software ensures that I can test, report, and track all my project tasks. This helps me be in sync with project progress.
We were searching for a simple bug tracking solution too and found some pretty cool platforms like Instabug, BugSee, ... The problem was that they are pretty expensive, so we developed a new platform that's made for everyone. BugBattle.
https://www.bugbattle.io
It offers something that's called in-app bug tracking, which allows you to report bugs (+ all kinds of useful information like screenshots, meta data about devices, ...) directly within your app. It's super easy & fast to integrate. I takes about 2 minutes or so to integrate it within your websites, apps, webapps. Def. worth trying.
In addition we added features like the BugBattle Challenge, which enables you to basically fight against others in bug fixing challenges. Haha, it should be fun to fix bugs :)
I am looking into developing a commercial application using PHP. Since I have experience in CodeIgniter and it has been working well for me, I decided to use it. Now, if ever my application comes to a point that it needs to grow and have to have custom modifications in the platform, is it possible to modify the CodeIgniter source code to the point that it's far from the original?
I'd strongly recommend not modifying the source code as this is the back bone of the application will make updating to futures releases of codeigniter impossible.
Instead you should be creating your own classes/libraries that extend the core bases. This is best practice.
The codeigniter users guide has some fantastic information regarding this, http://codeigniter.com/user_guide/general/creating_libraries.html
Good luck.
Don't modify it, extend it. Ellislab is good about releasing bug fixes and patches, and the last thing you want is to have to re-engineer all the updates into your new hybrid everytime they release updated source code. Plus, different features and bug fixes are released at different paces for the core and reactor, so unless you plan to lock your framework in at the current version, extending is the way to go.
The good news is CI is built for and encourages extensions of the source. The system folder and the application folder separation are a clear indication of how you should segregate your enhancements from the base libraries.
CodeIgniter is written in PHP. You can completely rewrite the framework anyway you like. So the answer is "yes".
There are many big websites that were written in a different language or build on a framework when they started and have been rewritten many times since. I think a lot of developers (mostly freelancers) are over-thinking when starting out. When I start a project, then I try to get it done and get it out in the web asap. If a website starts taking of - and most of the times start making you money - then you can always take the time to rewrite it.
I think it is a lot more important to spend time when you plan and design your database and tables. I think it is a lot harder to redo parts of your database later on then it is to rewrite the code that uses the data.
Just my 2 cents.
If you have used CI, then you should know that being a PHP framework that all of the source-code is there in the download, furthermore opening the system and application folders and looking through there will tell you a lot. Yes all of the source is there in plain English (plain programming English) and not only is it in plain English but has been extensively documented inside and out (literally that is in the source and in the user-guide). CI gained initial fame from that simple fact, that all code is extensively and meticulously documented.
Beyond all that, the question itself raises concerns that maybe you should study CI a bit further before writing commercial applications using it. Ci is a powerful and very easy to use PHP framework, but it is not a WYSIWYG. In my opinion, a coder should know his tools inside and out in order to be able to create a solid secure and trusted application. The first measure of which is to read the user manual, you should know at the very least everything in it, and since there are 12 sections in it that cover everything from extending CI libraries to creating your own libraries, and everything in between I would say you need to spend a little more time with it.
I want to say though, I am not being rude or trying to shame you in any way I am simply saying that you should learn the framework a bit more before venturing into a commercial application using it.
In the early days of PHP people realized how amazingly easy it was to use and how fast you could write an application with it. At the time the major options where very difficult for new and hobby programmers to use or involved expensive software to run, PHP was free, easy to learn and most of all ran on a free OS. It also took hardly any setup to get going, you could download PHP and essentially be programming in minutes. All of these factors lead to the almost destruction of the language.
Entry level programmers were destroying it with bits of code taken from other applications, never knowing (or caring) what the code actually did beyond the simple fact that it did what they wanted at the time, never considering or even investigating if the code might be harmful. Because of this practice PHP applications that had grown to Goliath sized websites, taking thousands of hits an hour were:
beginning to crash
being hacked to reveal sensitive customer/client data
generally crumbling all around the web
All because since the language was so easy to use that people had taken advantage of it and failed to take time to learn it. PHP was becoming a joke to other professional programmers and wasn't even thought of as a viable application language by many who had dubbed it "the copy and paste" language.
So my advice to you, please take the time to know your tools inside and out, what makes them tick, if they have any gotchas and where they are vulnerable. I understand that in order to learn a language to a professional level you have to build with it so I suggest that you take it slow with CI stick to the core for now. Trust me when I say that even in its purest form CI is an amazing and powerful tool that in the right hands can create awesome powerful web application, but in the uneducated/inexperienced hands it can create havoc and destruction.
So (stepping off of the soap box) I simply ask that if you are serious about creating commercial applications period that you take your time and learn your tools/language become as close to an expert on them as possible. I gurentee that if you do that you will always have work when you need it and you will spend less hours beating your head against the table or worse explaining to a client why their site is down.
I truly wish you good luck, just slow down and learn your trade and you will do just fine.
Yes, Codeigniter is an open source framework. However, I would advise against modifying the core of Codeigniter, as most files can be extended and rewritten safely without modifying the core files which will cause you headaches if you ever decide to update.
To extend a core class by default you would do this in Codeigniter. We'll extended the parser class for this example, but this applies to all classes pretty much. This link in the comprehensive user guide will give you all the information you need to extended and overload methods inside of a Codeigniter core class: http://codeigniter.com/user_guide/general/core_classes.html
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 3 years ago.
Improve this question
Hey all. I would like to get some insight on a question that I have been trying to find some information about. If you are the solo developer that is building a project from ground up, how do you manage the project? In the past, I have worked on a few personal projects that have grown into fairly large projects. In almost all of those projects, I have tried to wear the hats of all the roles that would normally be in place during a normal software development project (i.e. Product Owner, developer, architect, tester, etc.). It seems that when I leave the project for some time and come back, it is extremely hard to get back into the rhythm of what I was doing. So with that, I have some questions:
If I know the requirements (at this
current time), do I record them
anyways? If so, how do I go about
doing this, and how do I manage these
requirements? Product backlog,
features list, etc?
If this is the case, are full blown product backlogs or use cases a little overkill?
How does one efficiently appropriate
his/her time to each respective role?
What would be a normal flow of events
that one would follow? Start coding
immediately, write down user
stories/use cases, then go into
OOA/D?
What diagramming/modeling would be sufficient for this level? Domain model, class diagram, etc?
Basically, I was curious how everyone out there in the SO community would go about developing a project from inception to deployment when you are the lone, solo developer. What steps, documentation, and other project related activities are needed to help bring this project from an impractical, hobby project to something more professional? Any help, references, or suggestions would be greatly appreciated. Thanks in advance.
The most difficult part, I have found, about developing solo is that it's just tough to keep yourself driving forward. Even if you're doing this to make a living (AKA, running your own software business), unless you have pressing needs (AKA, you're going to starve if you don't make money) it can be difficult to sit down and just code.
From your perspective, I would recommend following good software practices where it makes sense to. For example, if I were a solo software developer, I would have no reason to create a collaborative development environment. All I really need is an SVN server, my IDE, and a place to record documentation (might setup a wiki or a website or something). I would personally create a realistic schedule to follow and would work on sticking to that.
As for level of effort of documentation, that really depends on you and the product you are developing. For example, I would definitely recommend recording your requirements. Unless your product is trivial, there is no way you'll remember them all and why you wanted certain ones over others. Managing a full backlog, however, can be a job in and of itself. In the solo programmer case this may not make sense.
Basically, the point I'm trying to get across (and should be followed with every project - not just in this case) is have just enough management that makes sense. The rest should be focused on the work and the development of the product.
Something else you may want to look into is reading this - Agile Programming Works for the Solo Developer. There are other, similar, articles out there. Might give you some good thoughts.
If I know the requirements (at this
current time), do I record them
anyways? If so, how do I go about
doing this, and how do I manage these
requirements? Product backlog,
features list, etc?
I have two lists of features:
A high-level view which states the scope of the finished product
A list of the features which I'm implementing in this iteration
Because I don't need to communicate it to other people (yet) I tend to write down the things that I don't know about the project (if I already know it there's no need to write it down): it's when it gets too complicated, or when there are details which I haven't defined but need to define, that I start to define them in writing.
I did however try to investigate/make a business-case for the project before starting coding.
How does one efficiently appropriate
his/her time to each respective role?
I did non-programmer, product-owner thinking at times when I had to be away from the computer anyway.
Apart from that, my cycle is:
Implement more functionality
Integration-test it
[repeat as above]
Every 3 to 6 months I compare the new-functionality-accomplished against my estimated schedule, and then recalibrate: i.e., make a new list of the highest-priority features to implement in the next few months.
What would be a normal flow of events
that one would follow? Start coding
immediately, write down user
stories/use cases, then go into OOA/D?
I started with working part-time or in my spare time, to make sure that I had:
Understood the required functionality
Made significant architectural decisions
Written any throw-away prototypes as necessary to learn new technology
After that I was ready to start developing full-time.
What diagramming/modeling would be sufficient for this level? Domain model, class diagram, etc?
I'm not using diagrams at all (except for sketches of the UI). By structuring the code, and refactoring, I'm able to know/remember/rediscover/decide which software components implement what functionality.
It seems that when I leave the project
for some time and come back, it is
extremely hard to get back into the
rhythm of what I was doing.
You need to comment your code more. If you leave the code, come back in two weeks, and can't remember how the code works, you need more comments.
If I know the requirements (at this
current time), do I record them
anyways?
Yes, for the same reasons stated above.
how do I manage these requirements?
A feature list is OK, provided you have enough detail in each feature to jog your memory.
How does one efficiently appropriate
his/her time to each respective role?
Break down each feature into smaller and smaller tasks, until you feel like you can do each task in a half day or less.
What would be a normal flow of events
that one would follow?
That depends on your development style. In general I would follow a clear but simple architecture, avail yourself of software patterns where practical, and provide adequate unit tests for your code as you go.
What diagramming/modeling would be
sufficient for this level?
Sufficient diagramming/modeling to make the project clear in your head.
What steps, documentation, and other
project related activities are needed
to help bring this project from an
impractical, hobby project to
something more professional?
Other than what I have already mentioned, make sure you have a good source control system and daily backups in place.
Good luck!
If you believe there is a chance that you're going to work on the project for some amount of time, leave it, and then come back to it at a later date...your best bet is to treat the documentation for the project the same as if you were working with a large team.
That means documenting requirements (even if they're from yourself), writing use cases (if functionality is going to be complex, otherwise some other form of documentation could suffice), and some level of UML diagraming (or other domain specific diagram) which could include activity diagrams/class diagrams/etc.
That way, when you leave the project for some amount of time, you can come back to a well documented idea and pick up where you left off.
As a side note, I try to do the majority of those things no matter what...that way if I ever find somebody interested in working on the project with me, I can get them up to speed quickly and get them on board with my ideas.
This is how I work, YMMV:
Keep a spreadsheet for high level of everything - list of your projects, and some top-level items/todos/reminders
Create a "project" folder for each product/project you have or work on, and create a strucuture to contain documentation and code for the project.
Keep a top-level "catch-all" document for each project, in the root of this folder. Keep you ideas, research, notes etc in this doc.
Then if you want to get organized, keep an MS project file (or similar) and plot out timelines for the various steps in each project. This is good for tracking progress on each project and make sure you arent forgetting anything. Basically keeps you honest with yourself.
And if you need to track progress on project work you are doing for clients, I understand Basecamp is a good solution for this. I am currently evaluating it for my own company. See www.basecamphq.com
Even as a solo developer, you should document at least the overall features of your project, and then the requirements for the particular feature you are working to complete, and then maybe produce a short pseudo-code for the functionality you're currently working on.
That way, if you do end up breaking away from that project, you can get back to it and see where you're up to easily enough. It's also pointless getting too far ahead of yourself with details for this same reason.
It's also a neat motivational tool for a solo developer - getting through and ticking things off is a way to show progress - something that you can start to feel you're not making when you're chewing through a couple of thousand lines of code and it seems like you're still miles away from actually having 'module x' completed.
Lastly - with regards to code comments - I at least try and fill out what actions/behaviour a new function should have in an outline, and then write the code in between the comments. Also, it is useful having plain English explanations of why you're branching in an if/else to support the logic in the condition...
I belive that better results in solo development one can achive with appropriate tools support and tasks that compensate lack of ohers people and help to organize working time. Any tool that generate metada with minimal create time cost describing your software is helpful.
VCS and tools for tracking user actity/code changes history - very important is to add good commit messages
mind-mapping tools for storing project related data (e.g. XMind), blacboard is useful too :)
time tracking tools (e.g. Toggl.com)
write a lot of acceptance test and use acceptance testing frameworks
Of course these clues also fits in non solo development :)
As a lone developer, I've found that your time is very expensive. This means that you have to balance sustainability and momentum - even though you are just one guy, you have to do things so that the you six months from now can go back and look at old stuff without wasting time, without spending so much time maintaining the systems that it compromises your flow.
Your question suggests that you are thinking in terms of fairly heavyweight tools and processes, but the 80/20 rule applies - for example, you can nail documentation well enough by TDD, using the doc tools of your platform to generate API docs, plus a Wiki for specs, lists, etc.
In that vein, I would suggest that you choose your platform carefully. The question about modelling suggests that you are using a platform that produce a lot of code and artifacts, but you may be able to get most of the functionality for much less management overhead elsewhere. Today I'm working on a .NET Web app that I wrote "the right way", but now realize that I could have delivered the same functionality much more efficiently in this case by using PHP with a PHP MVC framework to keep a clean structure.
Specific tools that I'd recommend:
A distributed version control system (much less overhead than centralized)
The most lightweight platform that you can use that has good tooling
A Wiki to easily capture and maintain small and large bits of content
Whatever testing framework that you can use, right from the start of the project
A lightweight TODO list system that you can access from anywhere
I used to work on a very small team (one dba and one C# developer). Even then I found it very useful to have written requirements, formal tests, source control and bug tracking (we used bug tracking for our features as well as bugs). It helped us to not forget anything and a year later when you were doing maintenance, you had something to research though to help you undersatnd what you did. Plus when the two of us left (as most people eventually move on) there was documentation there for the next person.
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
I'm facing developing a new web app in the future and I'm wondering how to decide what framework to use. I've settled on Python as my language of choice. But there are still may frameworks to choose from! More generally how do you choose between different similar technologies that are still in the works as the latest round of web frameworks are? I'm curious what your process is for deciding on technologies you've never used.
Recognize that no choice is perfect -- or even very good.
No matter what you choose, someone will have a suggestion that -- they claim -- is better.
No matter what you choose, some part of your tech. stack will fail to live up to your expectations.
The most important thing is "shared nothing" so that the components can be replaced.
After that, the next most important thing is automatically-generated features to reduce or prevent programming.
Look at Django. Lots of automatic admin features make life very pleasant.
There are a number of things you can do:
Download the frameworks and build something similar with them for comparison.
Look for comparisons by other people, but attempt to understand the bias of the reviewer.
Observe the community at work, see what people are building and the issues they run into when using the technology. Forums, blogs, mailing list etc are good places to check out.
Go to conferences and meet like minded developers interested.
You can also take the approach of using stable versions rather than alpha bits. After a while you might move closer the bleeding edge. People associated with the project in question are generally more biased than those approaching from other platforms, be careful who you trust.
Consider the impact of using a bleeding edge framework versus an established one. Sometimes it's important to your customers that you are on one perceived as stable. At other times this doesn't matter. How comfortable are you with fixing the framework itself? Great developers will learn the internals, or at least know enough to keep things moving whilst a bug is sent to the framework mailing list etc.
Consider some general best practices in building abstractions and reusable code on the python platform. You may be able to save yourself some work in moving to another platform. However, don't be a reuse junkie as this can limit the effectiveness of your use of the framework. The 37Signals guys are right when they talk about extracting frameworks from working code rather than building frameworks from scratch.
I know this is an old posting, but I am in a similar situation (again) and I think there are other people who may want to look for different opinions, and hear of (somewhat) successful experiences.
Since baudtack mentioned Python, I will try to answer this along the lines of my experiences using Python. Here is what has been working for me:
determine the scope of your project - outlining what your application is supposed to be able to do without introducing any programming or design notes will clarify your goals greatly
determine how you would like to work with your code, stack and data:
a. what sort of programming paradigm do you want to work with? i.e. object-oriented, functional, etc. do you want to play to your programming style or do you want to follow somebody else's programming style?
b. use semantic web or not? do you want greater control over URIs and their design? (I found web.py great for this by the way - It is my choice to create REST APIs in Python)
c. do you want to be trapped by framework requirements, or do you want a better separation of the application from the web component, i.e. use a framework to utilize your application as a set of modules, for example. My problem with Django was that I ended up not programming Python, but having to learn more Django than I needed to. If that works for you, then that is the way to go.
d. data stores... some sort of SQL vs. non RDBMS (xml databases like eXist-db with full xquery support) vs. OODBMS vs. a combination of the above? how complicated do you need this to be? how much control/separation do you need to have over how data gets stored and recalled in your application?
e. testing: unit tests... thank goodness for python! if your web app has the potential to grow (as they often do), having a sane and coherent testing platform to begin with will help out a lot in the future - I wish I had learned about this earlier on. oh well... better late than never.
f. how much control over the server do you need? hosting considerations? how much control over an Apache instance do you need to have? OS specific needs? I found that using shared hosting providers like Webfaction has been great. I eventually found I needed greater needs for flexibility and bandwidth. In other words, what can you get for your budget? If you have USD50 to spend each month, it may be better to consider a virtual hosting solution like Linode....
Finally, I echo S.Lott's sentiments that no choice for a solution is perfect, and are subject to obsolescence.
Experience trumps hearsay. I've found that prototyping is a huge help. Make a prototype that uses the features you expect to be the most important for various frameworks. This helps route out any features that may not work "as advertised."
In general though, kudos for being willing to look at new technologies.
I have a set of criteria in different categories:
Activity & Documentation
Is there an active user base?
Is there an active development base?
Is the support responsive and information accessible?
Are there user and development guides and reference material?
These are essential, there needs to be traceability of all of these to build confidence in the solution.
Ease of use
Are basic features easy and complex features possible? I typically give a new framework a test drive and try to roll out a set of use cases to see how intuitive the framework is to use.
Is installation intuitive and simple for a local/dev installation and production deployment?
How is it backed up and upgraded?
What is the effort and UX for implementing a "Hello World" type blog post, static page, menu item, and plugin?
How are versions dealt with for the core & plugins?
Example (on the topic of Automated Testing/Continuous Integration solutions)
Several years ago I evaluated several Automated Testing solution. At the time Jenkins and TeamCity were front runners and in the end I chose TeamCity because of the UX, active user & development base and quality of accessible documentation.
Example (CMS for a blog)
This criteria is also why I prefer to use Wordpress over other options. While wordpress has its shortcomings, the user and development base is strong and active which leads to a software architecture with more potential to evolve over time and maintain its relevance and a development community that provides quality plugins and themes to choose from.