If you really care about image quality (say if you're printing fine art photos), Inkjet is better. For almost all office environments where most printing is black text with the odd image that's not going to be hung on a gallery wall, Laser is more convenient and faster.
I don't know much PHP, but if you simply want a list of function names with a count of how frequently they occur, you can do the heavy lifting in grep. Note, I used GNU Grep which I had to install on my mac with brew install grep. The one that comes bundled on the mac is BSD Grep which has fewer options and doesn't support Perl-style regular expressions.
Here it is displaying the top twenty function names in Laravel.
I know it's a lot of moderator work, but I don't think there's a way out that won't require it.
I wonder, over the last week, how many
threads with leigitimate questions asked by real people were created?
how many spam posts were there?
Once people have been deemed non-spammers, one would hope that as a cohort, their posts need less moderation in the future. So in theory, acting as a quality gatekeeper keeps the forums clean in the present (iffy posts will never be visible to normal punters) and in the future (the dross has been skimmed and what remains are, hopefully, non-spammers).
There most definitely is a one-query solution. You'd effectively have to do both stages of the route I suggested in one go, using subqueries and a union.
Using views to simplify the process is not really a compromise, that's what they are there for. If you don't want them to be mixed in with your everyday database objects, use a separate schema (again, that's what they are there for!)
The good thing about doing it in stages is that it makes debugging much easier. If your results look a bit iffy or don't perform well and you need to start deconstructing a huge query with subqueries in order to begin working out what's wrong, the additional complexity becomes a burden. If your final query is simple and the views that it relies on are simple it's easier to find the problem. Better still, when you fix or optimise it, all the things that rely on it will automatically improve.
And here lies the problem. Not to mention the 11 year old green underlining thread that was just resurrected. The reason people like and keep going back to SO is because you just don't see spam and shitposting like this.
I'd do this in stages. Create a view where for each table you summarise totals by the month, you'll need to use extract or date_part to split the date into yearand month integer fields, which you'll group by, and sum to get the monthly totals. Then your joining of the two views becomes trivially easy.
Two simple steps are better than one complicated one.
If you're a developer and list your skills and past places of work there you simply become a magnet for recruiters and are inundated with requests. Some recruiters are ok, most aren't, and a large proportion of the offers I get are extremely low quality or not even remotely suitable.
Additionally, LinkedIn employs plenty of dark UI patterns which I really don't enjoy. "27 people have viewed your profile, click here to find out who! Not really"
Microsoft has a mixed record. LinkedIn was barely touched (and remains a cesspit of the highest order), Skype was mangled and is a shadow of its former self, as was Nokia. Others, like Yammer and aQuantive were just absorbed.
If Microsoft change too much too soon, GitHub users may leave for new pastures. However, if they stay hands off, it's not necessarily an awful move. Microsoft aren't the toxic open source hating company that Balmer ran, even if that memory is still fresh in our minds.
If you're using a capable database you can create a JSON field, but as with every choice there are pros and cons.
The pros are, of course, flexibility. Providing your JSON is valid, it can be stored, no matter how complex or nested.
The cons, funnily enough, are also related to flexibility. All of the tools your database provides you with to ensure data is valid and correct are gone, many of the options that your database gives you when it comes to quick and easy querying are now more complex or slower.
My advice would be to use it sparingly. If your data is relational, and in almost all cases it will be, use a relational database. If some parts are not, then model those bits using a more-apt technology (array or JSON data types in the DB or another technology entirely). Don't think about scale, especially webscale until you need to.
LinkedIn has an extensive API. Of course they restrict aspects of it because they don't want people competing against them, and Salesforce is Siloed so wouldn't really be suitable for the "professional dating" thing. Xing is the LinkedIn of the German speaking world.
Any of the people I typically encounter attending and hosting tech meetups and business networking events
Many of them on Daniweb? Any?
People who are looking to find mentors
Please don't pair me with Davy
People who work from home, who are missing out on the social aspects of working in an office environment, looking to meet other locals who work in their industry
Ok, this is a potential niche, I guess
People who work in sales or business development positions who are looking to meet potential clients one-on-one
I don't get this. Without pairing at the company level how could you know if someone is a potential client? Or are you talking about b2c pairings?
I know there is value in informed matchmaking but you need a high quality pool of users and companies. Can DW's userbase (which if I'm not mistaken is Dazah's too) support this kind of use in the real world?
I know DW has a lot of members but seemingly only a tiny handful of them are active, many are novices and I don't see any companies being represented.
In this arena you'll be up against LinkedIn, Xing, Salesforce; plus the countless companies that build on their APIs. They all have massive databases full of high quality customer and client record and sell b2b services on top.
Tldr; you might have the expertise but you need the data to back it up.