Related
I'm a 24yo Web Developer trying to improve my knowledge in this field.
I've been working on web since I was 12 and feel like I lack some fundamentals.
Many times I'm being rejected in interviews not because lack of talent, programming knowledge or a small portfolio (In fact, my portfolio is pretty big for a 24 yo dev), but because I can't answer many fundamental questions such as difference between/terminology about CRUD, REST, SOAP, OOP-related questions and such..
Going to university right now is impossible for many reasons so I was trying to get my hands on some books about dev fundamentals (mainly oriented to web dev). What are the best ones, and why? Which resources (Shouldn't necessary be books) should I look deeply into? And in the end.. What suggestions could you give to become a better developer?
I can only share from my own experience. During technical interviews, i had a cheat sheet printed and ready. That helped a lot on the telephone interview but also as a study guide. I can recommend the "PHP Zend Certification Study Guide" and php-fig.org to freshen up on Design Patterns and other things.
When the interviewer thinks you are qualified, you need to write code anyway. During the code writing you will probably write in OOP PHP with no framework. Prepare a simple mvc with some simple crud functionality, sessions and user login.
I know that SuiteScript is the NetSuite platform built on JavaScript that enables complete customization and automation of business processes.
I want to know that SuiteScript is in demand? How would be the future if I do following certifications
SuiteFoundation Certification
SuiteCloud Developer Certification
I've worked with NetSuite development (SuiteScript 1.0 & 2.0, administration, and integrating NetSuite to many other systems) for about seven years now. I have no NetSuite certifications, and I have never found a need for them.
That being said, some employers think highly of certifications. Whether you need the certs really depends on whether you can be self taught and whether the company you want to work for wants you to have them before you are hired.
I have been working on NetSuite for 4 years now. I have done SuiteScript 1.0, 2.0, workflows, searches, reports, etc (all normal admin and developer tasks with NetSuite basically). I am now certified Developer (meaning I passed the 2 exams you mentioned) and because I am a consultant I am now a certified ERP consultant as well. I will probably take the analytics, admin, and eventually SuiteCommerce as well.
So with that background, the answer to your question depends on what you want to do. If you are already working with a company who is using NetSuite, an end client probably doesn't care a ton about the certifications. If you are looking to get a job in this, then it may help you a lot. If you are looking to be a consultant, it will probably be a requirement at some point. For consulting companies, certifications help them look better to clients.
I also will add that I find that by studying for and taking the tests I have learned about features I did not have exposure to prior. This pushes me to learn those areas, talk to others, and better my overall skills beyond the exam itself. If you are only self taught, in my experience, you eventually fall into the "if your own tool is a hammer, than every problem looks like a nail". You won't have all the possible tools to do the best job
I personally found my certifications valuable. Last year, I completed the SuiteFoundation and Administrator exam, both of these guided me into different segments of NetSuite I had never used before.
I'm currently studying for the SuiteCloud developer exam, and I've had the same experience. It's forcing me to look into new modules and test out new functionality. With that being said, I'm a jr. level developer at best, so combining my js training with NetSuite-specific training is relevant.
There is a solid website that recently did a informal survey on this topic, if you want to learn more about value added from NS certifications you can visit: https://netsuite.smash-ict.com/
I recommend all NS newbies to complete the SuiteFoundation training. This applies to everyone, developers, admins, and end-users.
I have an e-commerce website and I need to display products in homepage based on user interest like advertisement showing on facebook and google based on the search we did on the internet.
Is there any API from facebook or google or any website for fetching user interests?
I have wondered how facebook, google, and booking.com collaboratively tracking us even if they are different companies.
Is there any common gateway or common interface where these big companies share user info by making a system with cookies to track among all as a centralized big data model for behavioral advertising?
I am looking for answers from experts for this. I really need to build a system for tracking user interest based on their search on google and other websites.
So you need to use something called recommender systems, using a machine learning algorithm, you'll recommend products to people based on ratings and interest. by using previous data of the same user or other users (just like when you get recommended videos on youtube).
this topic is too big for me to explain it step by step in here, and you need to first have a good understanding of primitive machine learning such as classification, regression ... etc
so if you're interested make sure to check a coursera course called Machine Learning (Stanford University) it's taught by machine learning rockstar Andrew NG, and it doesn't only teach you machine learning, but it takes you from somebody with no idea on the subject to an expert (technically) the course used MATLAB/OCTAVE and it has an entire section on Recommender Systems which is what you need, after you've finished just implement what you learned in the language of your choice !
PS:
you can always look up tutorial online for implementing Recommender Systems, but you will waste so much time because you would have no idea about what you're doing without understanding the theory which you will master in the course I've recommended, the course can also be found easily on youtube. but taking it for FREE in coursera will help you more because you'll have hands-on programming experience, on the different subjects.
For that google and facebook has their algorithm to track user movement and they use it for showing ads on their website.
i don't think that is available for common use.
I think you won't be able to Track there interest live Facebook, Google, Amazon, twitter. They are collecting your Interest form there own platform.
Also they manage large Add provider. SO once a Add has been clicked by you, it has been tracked. Also Google Play, itunes has access to your Phone.
In my organisation, we have some very inefficient processes around managing requirements, tracking what was actually delivered on what versions, etc, do subsequent releases break previous functionality, etc - its currently all managed manually. The requirements are spread over several documents and issue trackers, and the implementation details is in code in subversion, Jira, TestLink. I'm trying to put together a system that consolidates the requirements info, so that it is sourced from a single, authoritative source, is accessible via standard interfaces - web services, browsers, etc, and can be automatically validated against. The actual domain knowledge is not that complicated but is highly proprietary and non-standard (i.e., not just customers with addresses, emails, etc), and is relational: customers have certain functionalities, features switched on/off, specific datasources hooked up - all on specific versions. So modelling this should be straightforward.
Can anyone advise the best approach for this - I a certain that I can develop a system from scratch that matches exactly the requirements, in say ruby on rails, grails, or some RAD framework. But I'm having difficulty getting management buy-in, they would feel safer with an off the shelf solution.
Can anyone recommend such a system? Or am I better off building it from scratch, as I feel I am? I'm afraid a bought system would take just as long to deploy, and would not meet our requirements.
Thanks for any advice.
I believe that you are describing two different problems. The first is getting everyone to standardize and the second is selecting a good tool for requirements management. I wouldn't worry so much about the tool as I would the process and the people. Having the best tool in the world won't help if your various project managers don't want to share.
So, my suggestion is to start simple. Grab Redmine or Trac and take on the challenge of getting everyone to standardize. Once you have everyone in the right mindset then you can improve the tools you use for storage.
{disclaimer - mentioning my employer's product}
The brief experiments I made with a commercial tool RequisitePro seemed pretty good me. Allowed one to annotate existing Word docs and create a real-time linked database of the identified requisistes then perform lots of analysis and tracking of them.
Sometimes when I see a commercial product I think "Oh, well nice glossy bits but the fundamentals I could knock up in Perl in a weekend." That's not the case with this stuff. I would certainly look at commercial products in this space and exeperiment with a couple (ReqPro has a free trial, I guess the competition will too) before spending time on my own development.
Thanks a mill for the reply. I will take a look at RequisitePro, at least I'll be following the "Nobody ever got fired for buying IBM" strategy ;) youre right, and I kinda knew it, in these situations, buy is better. It is tempting when I can visualise throwing it together quickly, but theres other tradeoffs and risks with that approach.
Thanks,
Justin
While Requisite Pro enforces a standard and that can certainly help you in your task, I'd certainly second Mark on trying to standardize the input by agreement with personnel and using a more flexible tool like Trac, Redmine (which both have incredibly fast deploy and setup times, especially if you host them from a VM) or even a custom one if you can get the management to endorse your project.
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 5 years ago.
Improve this question
I'm sure that all of us have had to deal with telecommuters at some point in time, and I'm facing a situation now where my new project will have a "core" group of office workers and some off-site telecommuters. Not wanting to repeat past mistakes, I'd really like to know what ways people have tried in the past to effectively integrate telecommuters in an agile process, namely scrum.
My first fear is that the telecommuters will be the first ones to break the "daily scrum" routine. And, as human nature often goes, once that gets broken, it's hard to resume and get people back on track. Scrum recommends enforcing small, fun "penalties" for people missing or being late to the daily scrum, like donating a few bucks to a jar which would later be used to buy a case of beers for the end-project party or something. This is obviously something that would be difficult to enforce online.
The other big problem with telecommuters is the "out of sight, out of mind" problem. Aside from using webcams/skype/teleconferencing, what other tips do people have for keeping the team as closely knit as possible?
Also, what about dealing with telecommuters from different timezones? At the moment, we're lucky enough not to have this problem, but it's definitely a possibility at some point in the future. How have other teams dealt with this problem?
Instant messaging really helps with the "out of sight, out of mind" issue as their 'Status' (Available, busy, on the bog, etc) is visible to all. Also, by responding to messages they reinforce the idea that they're generally available.
I wouldn't worry about the Scrum meeting issue, joining a meeting via teleconf is often easier than attending in person.
Set the ground rules upfront. Don't be wishy-washy about them.
You've probably eliminated the "I got stuck in traffic" excuse for missing the meeting or whatever when they're working from home (or a satellite site) and so there's no reason to expect less out of them.
Take advantage of technology:
Use IM. We use it here and it is great for 'reaching out and touching' the guy four states away. Make it a requirement to be available via IM.
Use other tools to help break down the barriers. It'll depend on your situation.
If you're having the daily meeting, it should be clear to everyone that you're going to be asking the questions:
What did you accomplish since we
last met?
What are you going to be doing
today?
What's in the way that needs to be
moved?
Just because you can't see Matt in his cube doesn't give me a right to be lazy or unproductive and unresponsive. It's like dealing with my kids - let them know the rules and what is expected, then nobody can claim ignorance.
We have success using this tools:
Assembla for project management (source control, wiki, scrum tool)
Skype for voice communication
Google talk for im
We are team of 3 developers, in 6 time zones range.
I spent a year as the only remote guy on an Agile team. I called into a conference line for the daily scrum, as well as the planning/review meetings. I kept in contact during the day via IM/e-mail/phone.
I think it worked pretty well overall. The biggest constant drawback was not being able to see the physical whiteboard we used to track the scrum. We discussed moving to some sort of online tool to do this, but it never happened.
I was one timezone away, and I just considered it part of the telecommute tradeoff that I would work the hours that the rest of team kept.
As far as penalties for missing SCRUM - to a certain degree you should enforce this loosely, via the beer jar or whatever. But if someone is consistently missing/late required meetings, then their manager needs to address that.
The are a number of techniques that you can use - remember the purpose of colocation is to encourage collaboration and communication. A few things can help out.
If your team is all nearby - think about having core days of when everybody can come into the office. My current team allows working from home on Mondays and Fridays - and everybody comes in the office Tuesday through Thursday
For distributed teams, I have had good success with using Wikis instead of giant sheets of paper on the wall. The nice thing about wikis is that they encorage the team to edit the forms to meet the needs of the team as opposed to adapting to a more formal tool.
Another advantage of having a Wiki is each person can have their own page to share pictures about their vacations and hobbies - this makes remote people more real.
When you have a distributed team, I want to second the use of Instant Messaging that includes a status (Available, Away (grabbing a cub of coffee), Busy (in a meeting)) - these can include notes if people switch between working at home and at the office.
Webcams are inexpensive and valuable tool
Invest in a decent speaker phone (we like Polycom phones) for your group conference calls
Use tools like LiveMeeting to promote remote pair programming
A technique for doing stand ups over the phone is to have the person talking say the name of someone else in the group who has not gone yet - this keeps everyone paying attention.
For iteration (sprint) planning meetings - follow up with meeting minutes or a communication plan to make sure that everyone is on the same page. Not being colocated means a tad more documentation and intentionality on communicating.
Good luck
SCRUM and many other agile methods really do depend on physical proximity - it is hard to integrate telecommuters into any development process where integration happens frequently, but these particular processes are especially hostile to disembodied developers.
You will have to adapt the processes to the situation at hand. Video conferencing using webcams is actually very usable, and in fact yo might want to experiment with having their webcam on all the time in their cubicle/work area so people can just walk up and ask a question as they would with any other coworker.
But at the end of the day, you simply have to expect things to go differently for them - they aren't going to be able to fully participate in many processes if you are an agile shop.
-Adam
Make sure they attend the daily standup via webcam; as you said that's the first mis-step down a slippery slope. We try to have all meetings done with a RoundTable as well which really helps.
I've been doing this for two months (working in Canada with the core team in Dublin) and so far everything has been going really well.
See Scott Hanselman's writeup on his first year working remotely at Microsoft - definitely some good tips there. One Year Later.
Instead of a beer jar, the privilege of telecommuting itself could be part of the bargain for participation when required. If the team is not responsible enough to telecommute properly than they probably shouldn't be. More fun penalties for occasional tardiness could be to use a funny avatar to represent the person that is missing from the meeting.
Other methods of keeping people closely knit is using collaboration tools such as Wikis and project tracking tools such as Basecamp or FogBugz.
For differing timezones, early meetings will need to occur based on the furthest west time zone, unless one is on the opposite side of the world, which is a bigger problem. Then it will probably be based on who is in charge.
We have been able to manage daily scrums in our environment even with distributed teams over the phone.
It helps to use software such as Rally and Basecamp to manage the process.
One place I worked used Asterisk instead of a normal phone system. It worked well because when you are working from home, you simply log on, people can call your direct line number, outsiders don't need to know. Even though phone call cost are relativity trivial these days, having a 'always on' connection encourages more communication. The sound quality is better too.
For telecommuters/distributed teams, I recommend getting a decent phone - most desk phones lose the ability for folks on the other end to hear folks who are multiple feet away from the phone during a standup.
When you do your demos of working code for stakeholders at the end of the iteration, use webex or livemeeting or something to share the desktop and a camera to show the speaker so that your distributed participants can see what's going on. (Even better would be to ask your telecommuters to attend during iteration boundaries to participate in person).
I recommend getting folks together for a few weeks at the beginning of the project during the inception/kickoff phase so folks can build interpersonal relationships. It's amazing how helpful the face-to-face interaction up front can be to build a foundation for teamwork.
Use a distributed card wall. I like Mingle (http://mingle.thoughtworks.com), but I haven't used other tools, so can't comment on them.
For retrospectives, it's useful to have a proxy in the room using IM to communicate with your distributed team members... so that any comments the distributed folks have can be written onto a piece of paper (or post-it, or however you do yours).
As for your fears of "out of site, out of mind", my preference for things like this is to not create solutions for problems that have not yet materialized. If you find that your team is becoming disconnected (prime discussion points for retrospectives), then you can facilitate a team discussion on how to deal with any issues that arise. Again - the team should help identify the problem and the solution rather than having a manager or scrum master dictate solutions. Start with an assumption of trust.
Distribute Scrum requires good preparation. It is not just about the tool.
We supported many rollouts in distributed environment and there was one fundamental point - people.
The most efficient is to start with ALL people in one location. They have to meet in person so they can know each other as persons, not just someone virtual on the other side of the world. As I used to say - team members need to smell each other.
For release planning meet at one location, if possible. Change locations so you visit all of them, to have a context and understanding of culture, habits, persons. For sprint planning use video meetings, screen sharing etc. It is not necessary to travel (it would be too often).
Clear roles and team(s) organization must be established. You have to have Product Owner and Scrum Masters. You should consider if you do not want to get PO & SM as close to the team as possible. Definitely you have to get them into face 2 face meetings (it is about face, not a location) every day.
Definition of done, if agreed by the team, helps to have the same understanding what Done means. In distributed environment is a must.
You will need a good communication tools for daily stand-ups . We found usable to use Skype or Office communicator for dailies. We use audio AND chat. Especially in international environment chat allows you to understand people. Keep communication channel open after daily so team members can discuss what is necessary outside of daily report.
And, the most important, is to do regular retrospectives with all team members in all locations. Do not forget to implement ideas coming from retrospective. Teams in other locations will need a local support who will help them to implement ideas.
I work on a team of 5. We to facilitate our telecommute workplace we use:
Asana - Project and Task management
Google Talk + Your favorite IM
client (I used Pidgin)
RingCentral - VOIP Telephone
Gmail - asynchronous communication (i.e. email)
Dropbox - file transfer and
backup
Team Viewer - Screen Sharing, Training, and Presentations
Even with these tools it is easy to fall short on your process so it is important to establish some best practices for your team based on your dynamic. For example, we have two chief practices:
Communicate Often - because we are not in the same location when communicating it is easy to forget that you are working on a team. For our team, we update our tasks in Asana with comments describing ideas, obstacles, and task completeness. When immediate assistance or feedback is needed, don't wait, seek assistance via IM or email if (the person is offline).
Lean on the side of over communication - This pertains more to Asana comments and emails. However, in general we found it is better to give more information than is needed (within bounds).