Ever since I started coding back in 2008 I was addicted to it and I still am today. Typically not a day goes by that I don't touch some code. What the hell is my point... I'll get to it soon I promise. I have been writing PHP for roughly a year, I absolutely love it and HTML for 2, and I can't get enough of them. However, I want to broaden my skill set to a larger field. At the moment, I find HTML really boring, in fact the UI (specifically HTML) is the portion of my projects I want to do the least. I know some Ruby, Python, java, C, and Perl; but I want to become as proficient in a few of these as I am in PHP.
I want to focus mainly on Ruby/ROR and learning Objective-C/Cocoa. I have books out of the ying-yang, but I have yet to fully finish reading any of them.
Finally what begs the question, how in the world can I focus on all of this yet at the same time keep doing what I am going with PHP (which is making medium size applications). I have the determination and I'm not going anywhere (I'm to young to like die or something), any tips?
(This is really about productivity and not programming, but I think it deserves an answer) Find a project that you're so passionate about, that if you don't finish it right now you will go insane. Then find a piece of the project that you can finish tonight. Then find a smaller piece that you can finish before you go to dinner. Finish that piece. After that, don't break the chain.
Also, don't multitask. You think you're good at it, but you're not (don't worry, no one is).
Related
Most of us who do any amount of work in web apps/web design have seen ads for PSD to XHTML conversion services. Provided with a cash outlay and a source PSD file, these services claim to return professional-quality XHTML/CSS within a few days.
Coding up the XHTML/CSS for any project is often the most time consuming portion of the project. If these services really do produce professional-quality code, then even at a cost of several hundred dollars per page, it would be financially beneficial for me to use them.
So, what's your experience with these services? Quality code? Junk? Cross-browser functionality and graceful degradation? Etc...
Thanks so much! :)
I may be a bit biased being that I come from a front end development background, but I'll say this...
The bottom line is the person who does your front end has to:
A. Be competent
B. Give a damn
C. Take the effort to go through the tedious process of making sure everything is pixel perfect, semantically correct, and engineered to work well with jQuery enhancements.
Do you think that will happen for $99? Build it yourself or rewrite it later when it becomes an issue and you have to. A good front end takes planning just like a good back end.
Choose one that makes examples of their work available. For example, this company has done good work in my limited experience with them, and makes code samples available: http://www.psd2html.com/examples.html
Based on samples of their work, you can decide for yourself whether or not their work is what you consider usable and reliable. Otherwise, it's really too subjective a question for us to answer for you.
Q:
Lately ,i asked for testing a code ,,to detect the bugs and fix the problems ,,i find many problems ,, but the main problem here is the code it self ,, spaghetti code many many code lines and the tracing to fix problems is so difficult ,, plus some code is copied and pasted from the internet as it is without any modification,, no documentation is possible to this code,,the performance is so bad due to the heavy using of viewstate in every thing,, and it takes me a lot of time to fix the problems ,, and iam afraid of after all this time still other bugs may appear in the future .. how to handle this case ,,any advices concerning this issue will be a great help.
Start refactoring. This will not make only the code better readable it will also give you a btter understanding on how it works and what it does.
That's a very common situation - software was developed for some years and by many different developers and now you have to support it. You should fight the will to throw it away and rewrite the whole application - it is a big effort and chances are big that you will do many mistakes that are already fixed in bad code. See Joel article for more explanations.
In my experience the best way is to refactor the code. However it involves writing a lot of tests - unit, automated acceptance - and it will take almost the same time as rewriting, but it will be less pain
I think the mentality for working with spaghetti code is summed up quite well in Refactoring by Martin Fowler.
The picture that comes to my mind is surgery: The entire patient except the part to be operated on is draped. The draping leaves the surgeon with only a fixed set of variables. Now, we could have long arguments over whether this abstraction of a person to a lower left quadrant abdomen leads to good health care, but at the moment of surgery, I'm kind of glad the surgeon can focus
Basically what that means is start small, and update a single part of the code at a time. Little changes will add up to good, structured code in the future.
Of course, if there are major problems with the entire architecture, you may have to heed Cybernate's advice and start from scratch (unpleasant as it may be).
I would also write unit tests as well as refactoring as codymanix said. This does a couple things:
As you refactor, you will have some check that your refactoring won't break things.
Writing the tests is a good way of learning the domain knowledge embedded in the code.
Of course, there is an inherent catch-22 with adding unit tests to spaghetti code: it is usually hard to unit test, and you need to refactor it to be able to make it testable. But if you go bit by bit and start with the low-hanging fruit, usually you can make it readable.
Scrap the existing code and start afresh.
That involves lot less effort comparitively.
If that's not a possible option start with Refactoring using tool like ReSharper that will give a good start.
I am a software engineer working in Medical Imaging.I have just started using the language IDL and i feel very comfortable with it.As a new member in this field with a language like IDL, i would like to know the chances of IDL in this field.Can any one help me?
Well, so here is my biased opinion -> I'm heading the opposite way to you. I have used IDL (and before PV-Wave) on and off for ca 10 years (mostly MRI) and I'm now trying to part from it. Here is why. If you are proficient you can very quickly test something in an interactive / lightly scripted fashion. This is the typical use case of scientists; most have little CS education and are happy to grab any tool that seems to helpful. In fact, IDL is fairly good at dealing with largish arrays/images etc as you are likely to encounter in imaging.
However, it is not very pretty and coding gets increasingly awkward as your project size increases. If you are a software engineer, I suspect you'll hit the limits soon and will be cursing it no end. If you try to develop GUI code for people around you, you might be in for a rough ride. This is one of the main reasons I am moving over to Python + EPD with scipy and the likes. Also, binding to existing sophisticated image processing tools as you might need (registration, segmentation, etc) are not ideal.
A further complaint I have are the ongoing licensing costs. Even in an academic environment they are becoming prohibitive and I'd rather spend it on a Coop-student who could code for me than on ITT. A nice feature though is the ability to compile almost all IDL code into a sav file that others can use with a free IDL virtual machine.
Essentially, what it will come down to is how much your collaborators need you to use IDL. If it's fully your choice, I would look elsewhere. If there is a significant (and decent) code base, I would stay. The medical imaging plus astro community is dependent enough to keep this going for a while. If you do decide to hang on, I can highly recommend Dave Fanning's writings (his web page + his book + the google-group). He is somewhat of an icon in the idl community and certainly taught me things that were very useful. (Check out the mighty histogram function, I'm not kidding!)
Hope this works out for you.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I'm starting to learn about Scrum, and I'm interested in trying it out with our development team. I have a lot of questions about it...but my biggest mental roadblock is in the actual graphical design.
With our current development cycle [waterfall-esque], our graphical designer lays out the page with all the imagery and such based on a loose PRD. If we were to utilize the methods of Scrum, how would this development take place? I think we're used to seeing the big picture and driving towards it...as opposed to fitting the visual pieces together as we go, which is what I'd expect the Scrum policy for graphical design to be.
Would it be unheard of to at least wireframe all the functionality in the backlog? Or would it be wiser to--for the first sprint--design its functionality in such a way that we can add the new features of other sprints as we go? (i.e. When it's time for a new feature, discuss "Where would this fit into the current design?")
here's how I'd suggest you do it (ie, how we have tried to do it)
Pre-sprint 0: make sure you have a good vision of what you want to do. Doesn't have to be super detailed, but should not be "we want to build a website which is social"
Sprint 0: Developers tool up - setup the CI servers, work on the deployment scripts etc, so all the basic framework is done. At the end of this, you should be able to push a button (worst case: run a single command on a REMOTE server) which takes the code in your source control system, builds it, packages it, runs all the tests you want on it, reports that back, and if possible, installs it on a test server (or atleast results in a package you can install on the test server).
At this time, the designer is doing the wireframes. Their aim is to do basic wireframes for as much of the site as you think you need (think sitemap and flow not fields and pixels). Then, when thats done, work out with the PM's whats most important, and go into detail on that - wireframe. Not pixels YET.
Project managers and the like are working with the designer and the business/stakeholder, writing up stories and tasks for you lot to do and track. Obviously, they need to have an idea of the sitemap etc to do this.
This may take more than one sprint. start with one (I recommend 2-3 week sprints - 1 is too short, 4 is too long), see how much you still need to do etc.
So at the end of sprint 0, you have:
Lots of stories, in priority order (you CAN add more later, infact you will always as requirements change)
A sitemap (ie, a general idea of what the whole thing is going to contain)
Wireframes for the first block of work
All your tools are working and setup
You CI, bug tracking, source control and deployment systems are in place
So then you begin sprint 1
Keep in mind that for the first 3-4 sprints, you will not know how much work you can do in the sprint, so EXPECT to get it wrong! Take off as much work (in the priority order the business/PM has put them in) as you think you can FOR SURE get done. you can always take more later!
You lot develop those pages, and the designer(s) wireframe up the next block of pages (as determined by the PM's). Maybe the designer does the art for those pages, so you can do it in the next sprint
So, you are developing what you have, and the designers are working on stuff for your next sprint.
Of course, they could have a scrum process going too, just they started a sprint earlier!
now repeat until you run out of work
during a sprint, if (say) a requirement changes or something new is added, then a new story is written for that, and it's scheduled into the work. If it's super high priority, it may go at the top and be the top item for the next sprint (which will be 1-2 weeks away, usually). Or it may be a nice to have, so it goes at the bottom - the business decides.
PM's/designers need to know they can change things, but changes DO have consequences, so it's not in their (financial) interest to chop and change back and forward. but requirements DO change, and XP and Scrum deal with this better than waterfall.
Dont forget:
you can stop a sprint at any time and go back to planning, eg if the requirements change too much, or you run out of work
you can schedule more work than you have time to do, as long as that work hasn't been committed to (ie, it's "extra" or "stretch" work)
Your PM should be able to predict when the project will end - look at how much work you did in the last sprint (your velocity), and divide the amount of work left by that number, and you get the number of sprints to go. Easy.
Oh, and read up on story points - dont estimate stories in hours or days. Use points. To bootstrap that, just make the first story you estimate (say) an 8 (the sequence is 1,2,3,5,8,13,21,40,60,100,infinite). Then take the second story, and estimate it relative to the first - is it double the work (13)? half the work (5)? about the same (8)?
At the end of the sprint, add up how many points you did, and that's your velocity. The max amount of work you can COMMIT to do doing in the next sprint is that amount. You CAN always stop the sprint early, or just pull more work off the backlog etc if you run out early. As you go along, your velocity will stabalize.
Damn, I'm sure there are books etc on how to run it, so I'll stop :)
I strongly disagree with the answer provided by Jason. The whole point of Scrum is to get rid of the method where designers first "do their thing" and then go on to other stuff. That's completely and 100% against all lean / Scrum principles!
The way to incorporate designers in a Scrum process? Throw 'em into the mix! Make sure you're not just wrapping a waterfall project into Scrum as that's the best way towards failure! Scrum only works when it's implemented without exceptions. "Scrum, but..." is the worst project model. Organize work so that it's possible for concurrent designing and developing. Don't overdo initial design, but make it a push-pull situation, where both sides of the coin influence the other. The point of Scrum is to iterate, iterate and iterate, so take full benefit from that.
Also, it's pretty lean to actually shun traditional Photoshop-based design altogether. You can read more about this from this excellent blog post in Signal vs. Noise:
http://www.37signals.com/svn/posts/1061-why-we-skip-photoshop
I've done this before where the Designers did their thing in the early iterations, and their work product was used by the dev team in later iterations. As the dev team started work, the designers would move ahead to other parts of the project, or possibly to other projects.
I think we're used to seeing the big
picture and driving towards it
You can still do this. Your designers can do a bigger up-front design, and the dev team can use Scrum to iterate towards that.
For the the design part in sprint 0 you can use a technique like Styletyles (http://styletil.es) to determine the graphical style needed for the project. So you dont need a big design upfront and still be agile when you are sprinting.
It's easy peasy! :) Well, let me share how do we do it.
First Sprint
1) Product owner creates wire-frames and add to backlog (we use Yodiz, www.yodiz.com)
2) Our graphic designer create mockups and put them on mockup sharing tool (www.concept.ly)
3) Our developers work on setting up servers. If everything is already ready we have pretty smart Product owner, you will always have items in backlog to select.
Sprint Two
1) Developer start working on the finalized mockups, which were finalized on conceptly.
2) Designer work on other wire-frame added by product owner in backlog.
I told you it's easy!
I'd like to share . I'm the scrum master for a development team of a future social app. This team has in it 1 User Interface designer, 1 User Experience designer(me), 1 front end developer(css,ajax etc), and 3 programmers.
This is our first ever project using a SCRUM framework so it's been quite challenging. The trend during our scrum daily meetings is that our design work are never quite done done because our initial product backlog had stories like 'User wants to be persuaded to sign up' and then we added on that story a 'way to demo' so from there we could determine what needs to be done (i.e. we need to do wireframe, have copywriting done, etc...)
That, could be done better. Itemize every task based on that story, and estimate time for each task. For example, during product backlog, we could from there on create these in order: Site Maps > Task Flows > Wireframes
Now the question is, do we do all these in a sprint? Or should we do this even before any sprint? Defeats the purpose of scrum if we do out of sprints right?
Those who have done user experience design will know that these tasks take quite an amount of time to prepare. So why not make all these part of a sprint as well? Get programmers involved in these tasks as well.
Wireframing is very very important throughout the duration of the project. It's like the blueprint to a building, where its used from start to finish.
So, do an initial wireframe based on the product backlog during your first sprint. And adjust the wireframe accordingly during every other sprint. Our programmers will design their code based on the task flow and then create it visually based on the wireframe.
Oh, btw, dont bother too much about how the product is going to look like (tho having an intial design mockup is always a good thing). Instead, focus on the user needs and wants, and design a very user-centric flow to achieve just that. Our Designer later then figures out what kind of interface he is going to devise. If the wireframe was done proper, the designer will have very few problems designing the user interface. Same goes for creating copywriting.
In summary, work hand in hand during every iteration. For beginners out there (like me) give SCRUM a chance to work for you. If it can work for companies like fantasyinteractive.com , so can it work for you n me :)
p.s. for great wireframes, use omnigraffle (mac) tis the shite!
If we were to utilize the methods of Scrum, how would this development take place?
while this post is quite old, it prompted me to research on my own. i found Jeff Patton's "Twelve emerging practices" for UX designers/practitioners, which i thought to be apt to this question specifically, and quite a useful frame set:
Drive: UX practitioners are part of the customer or product owner team.
Research, model, and design up front - but only just enough.
Chunk your design work
Use parallel track development to work ahead, and follow behind.
Buy design time with complex engineering stories.
Cultivate a user validation group for use for continuous user validation.
Schedule continuous user research in a separate track from development .
Leverage user time for multiple activities.
Use RITE to iterate UI before development.
Prototype in low fidelity.
Treat prototype as specification.
Become a design facilitator.
if you'd like to dig deeper, jeff spells it out agileproductdesign.com.
This question is not coming from a programmer. (obviously) I currently have a programmer making a website for me and I am realizing that he isn't going to completely work out.
He has already done quite a bit of work and the site is almost there but I need someone who is better to take it the rest of way. The site has been done in asp.net and I am wondering how hard it would be for a more experienced programmer to take over and finish the work he has already done?
In general, is it hard for an asp.net programmer to come in towards the end of a project and fix what needs to be fixed?
There is five different pages on the site with two overlays for a signup and sign in. (Five pages with many different versions) There is a database and client-side scripting. AJAX was also used. It's a site somewhat similar to SO only not quite as complex and about something completly different. I would say think of something that falls somewhere between Stackoverflow and Craig's List. Thats all I can say now as I don't know the technical words.
You'll probably find that the new programmer will want to rewrite most of the code from scratch. If you are on a tight deadline or tight budget and can't accept a complete rewrite then you will need to hire someone that is not just good at writing good code, but good at reading, refactoring and improving bad code. It is two completely different skillsets and the second is much rarer. Depending on the quality of the existing code (and I'm assuming here that it is not good), your new programmer may end up rewriting much of the existing codebase just to understand what is going on.
Depends on how good the previous programmer was and on the complexity of the project. It might be anything between trivial (well commented source, some high-level docs, unit tests, modular or simple project), to "this crap needs a complete rewrite" (no docs, custom "let's try this" solutions, etc.). If you're not a developer it might be really hard to tell. And other people won't be able to answer without more details.
I'm no asp.net expert, but I suspect the ease with which the replacement will be able to finish the project will depend mostly on just how bad a job the first programmer actaully did. Bad code is painful to fix in any language. :)
A good idea will be to have them work together,for say, a week or two. This will help the new programmer get some much needed training about your current system.
You may find that although the site is almost complete, the successor will have to spend more time than anticipated when performing alterations, as this person will have the mental model of the software that the current developer has. Hence the need to next developer to "re-write" the code base.
If you can, you'll want to ensure that the code base that you have built is maintainable. That is, the solution is built in such a way that it can support alterations easily. As Mark Byers suggested, you'll want to get someone who can not only program but can also re-work your existing code with the goal being that someone else will inevitably implement future changes. If the software is something that you need to keep working for an extended period you'll want to make the investment in making sure that it new functionality can be added easily.
Remember this experience described at The Daily WTF. Take appropriate precautions.
Generally if the site is set up in some sort of standard fashion then another programmer should be able to pick it up easily. if the existing programmer did things to obscure the code then it will be hard for another programmer to pick it up. Basically the question is how readable is the code?
If the current programmer is unwilling to communicate the true status of the project in a professional, non-technical manner, then give him an ultimatum - your way or the highway. Odds are he will be more forthcoming if he knows you mean business. Make sure you have a copy of the latest code before broaching the subject.
It sounds like you are going to end up hiring someone else anyway, especially if you're asking these kinds of questions at this stage, so you might as well go for broke.
As Mark Byers said, it takes a seasoned developer to take someone else's code and resist the urge to "pretty it up" in order to bring the project to a working conclusion!