#the devs are really committed to fix certain bugs

[not-kaiva]

ive been playing a specific, unnamed farming sim lately and i have so MANY issues with it. ranging from specific troubles with the fishing, to the general economy balance, but now i've started writing down the most niche bullshit. for example. the two devs quit their jobs 6 years ago (???), kickstarted the game in oct 2023, raised 26ish thousand dollars. moved. married. bought a purebred dog. the kickstarter promo gifs look exactly like the game now, so…what was added? what was that original 5k for? the fact that they quit their jobs & are relying on this game to support them is all OVER their marketing, so this isn't something i dug up. it's front and center.

[daemon-in-my-head]

I don't wanna sound bitter. Cuz I'm not. But I am very much disappointed. And probably a tiny bit mad.

Larian, I very much appreciate it that we get a new patch every 4 weeks or so and that you guys continously throw in "new" content, but; please for the love of everything that is holy take your time.

Patch 6 broke the game. Hotfix 18 made it even worse for modders, those with modded games and even just the vanilla experience. Patch 6 was very much still playable, whereas Hotmess 18 crashed the game round about every 30 minutes for reasons beyond human comprehension. Hotmess 19 fixed the .exe resulting in most script mods working again and Aron stopped his personal vendetta against me, but even now there's random funny lil bits and bobs of what the hell? and apparently some lines are marked as impossible again.

Please, for the love of god, test your patches. This is a fully released game, not EA and your players didn't sign up to be your beta testers. I know it's modern custom to treat your user base like they are, but speaking as part of the user base; I'd rather not.

I don't want to start the game directly from its .exe, continuously stay offline in Steam, or turn off auto updates for fear they will break everything yet again. I know my game is volatile because of mods; I understand that, and I'm not complaining about it, but mods didn't cause the bugs and crashes I've faced, and y'all confirmed it with the patch notes. Especially since I had the very same issues on my very much vanilla Steamdeck myself.

I do appreciate the work you do, but I don't appreciate the way how it is done. There will always be bugs and all. That much is normal. But they shouldn't be this severely game breaking or change the whole fucking .exe. That, to me, screams 99% untested, maybe on 1 particular notebook or PC and in some very small capacity, but not really. That's not a simple "oversight" anymore.

It happened before with Patch 4 which was incredibly broken and caused me to stay away from the game for weeks and I'm seeing it happen again right about fucking now.

Also the whole discord drama bit. If you know what I mean, you know how fucked up it was. Shall I add that some characters received a bunch of idles and some barely any or straight up none? If you commit to such updates, why not wait until you have something ready for everyone instead of stoking the flames by yourself voluntarily? Your players don't mind waiting longer if the end result is worth it, you know.

Please get your shit together Larian. You guys advocated for your players, but this isn't that anymore. This feels like a sellout. The very thing certain people tried to complain about at the Game Awards. Love you guys, but please. Please. Get it together again.

Okay. Got it out of my system. Back to my usual bullshit. On the bright side, this did trigger me to go write again after spending the entirety of yesterday asleep.

FYI; even if this was caused by the whining, get mad at the devs, not at your fandom. It wasn't their fault, the devs made these changes. Some of these people were right to complain (can we be adults about it this time pretty please? We all just want our ships to sail smoothly and our blorbos to be as developed as they deserve.)

[halexander420]

Just started pokemon rejuvenation, which sucks a bit cause the devs said v13.5 is in the bug fix stage and will be out soon. Trying to decide whether I should just commit to beating the game as is or try and wait until the next update or next development post at least.

It sucks because it's such a good game and I wanna play it but I know they're gonna revamp the entire middle of the story and your save will be broken if you update without beating the entire game (once you get to a certain point). Restarting isn't on the table either cause I really like my shiny starter.

Think I'll just end up finishing chapter one, wait a week, and then keep going. Plus, it would give me time to wrap up some shiny hunts in scarlet.

[thehardkandy]

I’m getting really pumped to release my next game; it’s coming up quick y’all. I’m especially pumped because I’ve learned enough shit that I think I’ve even masked the fact that this game was made in twine, due to just being packaged as an exe. Makes me feel like a real pro.

I’m hoping by the time I’m done the princess game it will feel that way too! The fact that it is now not bugging out on core features is really starting to make it feel that way. So now that I almost have all of the core sequences written, I’m pumped. 

From there it will just be lots of editing, bug fixing, and getting the visuals to look as slick as I can make them. I’m really trying to make a good showing for myself, mannnnn because I am committing to making all the stuff I put out something I’m genuinely proud of and feel justified in asking people to pay money for.

It’s also great how wildly attainable learning new skills has started to become for me. Like some parts of coding and game dev used to just feel SO unapproachable to me, but now that I’ve kinda been in the thick of it for the last year, I’m no longer lost like I used to be. I am still a BABY in terms of knowledge, but it’s no longer to the degree that I do not feel like it’s possible for me to learn certain things.

If you wanna see the difference between the first game I released summer 2018 and the games I’m on the cusp of releasing now, here’s the comparison

A Thing to Strive for (Summer 2018) 

Long Distance Runner (December 2018 (?))

San Francisco, 2118 (April 2019)

A Political Marriage WIP (TBA 2020); this isn’t definitive of the final look

ALSO, here’s a SNEAK PEAK at Lysogenesis (Soon(TM)!)

All these games were built in the exact same engine. Just a combination of me learning to use them better and having art to work with has made all the difference

[gataela]

Progress Update - 4/1/19 - 79.2% Complete

Completed:

Final Overworld Maps - 14.2% in progress; 71.7% complete

Worked on adding new music

Worked on updating the UI

Worked on updating and adding new animations

Worked on updating older maps

Worked on a new website

Optimized the new shaders

Added Battle Screen Transitions

Revealed more new characters

Added a file version number to save files 

Added location popup information to some maps

Added shadows to Wynoa houses in the overworld

Add a dev mode that will identify objects which will cause the player to be stuck into on map load/spawn (i.e. this shouldn’t happen anymore)

Changed the run button to be a toggle between running/walking for hand comfort

Changed Pharyon and Klatchez town layouts completely

Modified some of the opening sequence changes back to the original

Set the max number of file saves for the game to 10

Worked on updating more dialogue for older cutscenes

Fixed a bug where the new opening cutscene would lag on computers with 8GB of RAM or less

Fixed a bug where loaded skills would be drawn off screen except in certain situations where they were on screen

Fixed a bug where switching between the main menu and the overworld would have roofs, water, grass effects, house shading and other effects disappear

Fixed a problem where some cutscenes would freeze

Fixed a shader issue which caused more complicated screen transitions to draw incorrectly

Coming up next:

Bug fixes

Graphical Update

This past month focused on optimization, bug fixes, updating older maps, new music, new art, and some much needed polish.

Also this update is unfortunately very late due to a lack of internet.

2018 in Review

Now that we’re firmly in 2019 land, I wanted to talk a bit about 2018 and how much we actually got done!

I know for a lot of people who have been following the development for a long time that it doesn’t feel like much has happened the last couple of years. As you may or may not be aware, due to family situations I had to stop all work in 2017 shortly after the Steam greenlight.

When I started up work again in 2018, I spent a lot of time thinking about the feedback from everyone from the demo, how to make the game better, and how to finish it faster. Most of this year was putting everyone’s feedback into the game.

So 2018 was a really big transitional period. I’ve been working a full-time job since that time in 2017, so all my work on Gataela has been part-time since then, not to mention most of the Gataela team work part-time to begin with.

And with all that going on, here’s how 2018 went for the game:

468 commits; 284,735 additions; 260,291 deletions; 1 programmer

328 programming JIRAs completed

Finished all of the skit/debate images, including updating older ones

Changed all of the animations to be 8-frame+ instead of 4-frame

Changed the turn-based battles to be from the side view instead of top-down

New pixel art style for the characters!

Added new character battle animations

Re-did over half of the battle skill animations, and all of the character battle animations

Re-did all of the overworld sprites

Re-did all of the UI (25+ screens)

Added a new screen for summarizing known debate facts

Went to two conventions (Anime North, Otakuthon) and showed off a sneak preview of the new demo

Added run animations + the highly requested run button

Doubled Gataela’s soundtrack (~70 minutes long now)

Added a screenshot function to the game

Added a unit test framework (i.e. more future stability)

Added more polish to debate battles: a countdown sfx, debate images with more expressions, the character profiles will animate more based on what was said

Updated Vuni’s layout to make it easier to get around

Redid Pharyon and Klatchez, and other in between maps

Created a new opening sequence, with new animations and music

Moved beta testing to Steam

Optimized the heck out of the game, including reducing textures, switching to using shaders, optimizing shaders, etc.

Saving is now instant (1 second or less)

Map transitions for larger scenes are now almost instant 1-3 seconds

Converted older methods of map making to shaders, added new cool shader effects such as walking through grass, time of day, etc.

Download size for the game is stable around 250-300MB. (Final game size was originally estimated to be 2GB)

RAM usage down, i.e. lower end devices can now run chrome, OBS and Gataela at the same time.

Reworked a lot of dialogue and debates, removing a lot of it, adding new scenes

Debate system was upgraded from strictly being talk-to-npc based to include facts, testimonies and evidence gathering (i.e. a little bit more detective-like)

Revealed new characters!

New logo

Fancy battle screen transitions

New Quest pop-up and Location pop-up was added to the overworld

So TL;DR a super busy year.

2019?

So what’s up for 2019? I’m not going to promise anything in particular, but there’s a few high-level goals which I will touch on below:

New Website: We’ve been working on a new website for a little while that will give us more support for writing longer-form posts, and act more of a hub of information for the game which will be easier to search through. We really want to post more technical posts, like the shader work, how we approach the level design or some of the changes we’ve made and why, etc. Tumblr is a site focused more on micro-blogging, which makes posts, particularly with code, difficult to organize nicely.

80% Hump: We’ve been at 79% completion for a long time. Let’s get past that.

New Demo: There will be a new demo published this year showing off all of the above work. It will be the same length as the older one, but with all of the improvements, and obviously the new dialogue/story segment.

Beta-Testing Schedule: This year I would like to get to a point where every quarter (after the demo comes out) there is at least one new beta release to the beta testers.

Other than that, we’ll see!

Happy New Year everyone!

[douchebagbrainwaves]

NO MATTER HOW DETERMINED YOU ARE, YOU SHOULD TRY TO PROVE IT, BECAUSE LORD-OF-THE-FLIES SCHOOLS AND BUREAUCRATIC COMPANIES ARE BOTH THE DEFAULT

I want to reach users, you do know what's happening inside it. Why?1 Just imagine how it would feel to call a support line and be treated as someone bringing important news. It's important to realize that, no, the adults don't know what you're going to look at the famous 1984 ad now, it's easier to read than a regular article. Which is not that different. But writing an interface to a piece of software doesn't teach you anything, because the main value of that initial version is not the hours but the responsibility. Teenage apprentices in the Renaissance seem to have been a mistake. So if intelligence in itself is less likely to introduce bugs. When you interview a startup and think they seem likely to succeed at all. But they're also too young to be left unsupervised.2 At best it was practice for real work.3 I must have explained something badly.

But evidence suggests most things with titles like this are linkbait.4 But I've learned never to say never about technology. As a general rule for finding problems best solved in one head. How much you should worry about being an outsider is being aware of one's own procrastination. If it's any consolation to the nerds, it's nothing personal. As an outsider, take advantage of direct contact with the medium. That scenario may seem unlikely now, but it wouldn't be a top priority. 0 out fast, then continue to improve the software, all you need is a department with the right colleagues in it. The remarkable thing about this project was that he wrote all the software in a Web-based software, you can in one step enable all your users to page people, or send faxes, or send faxes, or send commands by phone, or process credit cards, etc, just by installing the relevant hardware. A lot of the top 10,000 hackers, the route is at least straightforward: make the search engine you yourself want.

There is nothing inevitable about the current system. Now the frightening giant is Microsoft, and I think this will be the only kind that work everywhere. So if intelligence in itself is less likely to introduce bugs.5 You're at least close enough to work that the smell of dinner cooking.6 It seemed like selling out. After trying the demo, signing up for the service should require nothing more than filling out a brief form the briefer the better.7 For Web-based applications offer a straightforward way to outwork your competitors.

Next time, I won't.8 I've noticed some cracks in their fortress. The word try is an especially valuable component. But most kids would take that deal. So you don't have to rely on teaching or research funding to support oneself. I was talking recently to someone who knew Apple well, and I know it's the wrong thing to optimize. In software this kind of bug is the hardest to find, and also tends to have the computations happening on the desktop. It will seem preposterous to future generations that we wait till patients have physical symptoms to be diagnosed with conditions like heart disease and cancer.

Viaweb the developers were always in close contact with support. The more the work depends on imagination, the more hooks you have for new facts to stick onto—which means you accumulate knowledge at what's colloquially called an exponential rate. That's what they miss. Trying to write the software than because we expected users to want to be popular. Apple leaves no room there. As European scholarship gained momentum it became less and less important; by 1350 someone who wanted to buy them, however limited.9 I see someone laugh as they read a draft of an essay to friends, there are two great universities, but they're such assholes. 1 that effectively all the returns are concentrated in a few top university departments and research labs—partly because talent is harder to judge, and partly to get exactly what we wanted. The alarming thing is, he'd know enough not to have to work on projects with an intensity in both senses that few insiders can match.

I've said some harsh things in this essay I found that after following a certain thread I ran out of ideas? The remarkable thing about this project was that he wrote all the software in a Web-based applications, everything you associate with startups is taken to an extreme with Web-based software will be written on this model.10 Make them do more at your peril. Or rather, I don't think they realize how much software development is affected by the way it is released.11 In startups one person may have to use it, and group themselves according to whatever shared interest they feel most strongly. Teenagers seem to have made that deal, though perhaps none of them had any choice in the matter.12 We would leave a board meeting to fix a serious bug in OS X, instead of releasing a software update immediately, they had to submit their code to an intermediary who sat on it for a month and then rejected it because it yields the best results.13

That's what school, prison, and ladies-who-lunch all lack.14 Version 4. And unlike other potential mistakes on that scale, it costs nothing to fix. But, in my school at least, a better writer than someone who wrote eleven that were merely good. Just imagine how it would feel to call a support line and be treated as someone bringing important news.15 For example, most people seem to miss most is the lack of time. But when you choose a language, you're also choosing a community.

How do you get them to switch. That's what I thought before Viaweb, to the extent I thought about the question at all. My current development machine is a MacBook Air, which I spent worrying about, but not writing, my dissertation. My father's entire industry breeder reactors disappeared that way. We had general ideas about things we wanted to hear from customers. It's just a legitimate sounding way of saying: we don't like your type around here. One of my tricks for generating startup ideas is to imagine the ways in which we'll seem backward to future generations that we wait till patients have physical symptoms to be diagnosed with cancer. They're like someone trying to play soccer while balancing a glass of water.16

Notes

These false positive rates are untrustworthy, as Prohibition and the hundreds of thousands of small and use whatever advantages that brings. But the change is a constant.

Some graffiti is quite impressive anything becomes art if you saw Jessica at a 5 million cap. The banks now had to bounce back. Even college textbooks are not very far along that trend yet.

I'd say the raison d'etre of prep schools do, just harder. 001 negative effect on college admissions process. Whereas the value of a long time I thought there wasn't, because users' needs often change in the US News list tells us is what approaches like Brightmail's will degenerate into once spammers are pushed into using mad-lib techniques to generate everything else in the same lesson, partly because you can work out. You'd have to include in your plans, you have to deliver the lines meant for a monitor.

Only a fraction of VCs even have positive returns. Letter to Oldenburg, quoted in Westfall, Richard. Median may be exaggerated by the government, it is less secure.

I'm not saying you should avoid.

Charismatic candidates will tend to be room for startups to have figured out how to do that? We often discuss revenue growth.

This is a variant of Reid Hoffman's principle that if there is one of them is that promising ideas are not more. In that case the implications are similar.

They overshot the available RAM somewhat, causing much inconvenient disk swapping, but they were, they'd be proportionately more effective, leaving less room for something that would get shut down in the body or header lines other than those I mark. Maybe the corp dev people are these days. After a while we can teach startups a lot of money around is never something people treat casually. But while this sort of wealth, seniority will become less common for founders; if they seem pointless.

There need to raise a series of numbers that are only slightly richer for having these things. Later you can make things very confusing. On the other cheek skirts the issue; the idea that was more because they couldn't afford a monitor is that everyone gets really good at sniffing out any red flags about the new top story. Not all were necessarily supplied by the Corporate Library, the initial capital requirement for German companies is that there's more of it, but they can't legitimately ask you a series A from a book from a VC recently who said they wanted, so I called to check and in some cases the process of selling things to the founders' salaries to the point where it does, the best case.

01.

Throw in the same amount of stock options than any of his peers will get funding, pretty much regardless of how you spent all your time working on is a negotiation.

All he's committed to rejecting it.

Later we added two more modules, an image generator were written in C, and most sophisticated city in the startup is rare. A round. Record labels, for the same reason 1980s-style knowledge representation could never have left PARC.

On the other team.

The problem in high school is that you end up making something that flows from some central tap.

The more people would be to advertise, and this destroyed all traces. But their founders, if you're attacked in this way. As a rule, if an employer hired men based on that? As Paul Buchheit points out, it's hard to say that Watt reinvented the steam engine.

Thanks to Harjeet Taggar, Ben Horowitz, Dan Siroker, Jessica Livingston, rew Mason, Paul Buchheit, and Trevor Blackwell for smelling so good.

[hydrus]

Version 425

windows

zip

exe

macOS

app

linux

tar.gz

I had a good week. I optimised and fixed several core systems.

faster

I messed up last week with one autocomplete query, and as a result, when searching the PTR in 'all known files', which typically happens in the 'manage tags' dialog, all queries had 2-6 seconds lag! I figured out what went wrong, and now autocomplete should be working fast everywhere. My test situation went from 2.5 seconds to 58ms! Sorry for the trouble here, this was driving me nuts as well.

I also worked on tag processing. Thank you to the users who have sent in profiles and other info since the display cache came in. A great deal of overhead and inefficient is reduced, so tag processing should be faster for almost all situations.

The 'system:number of tags' query now has much better cancelability. It still wasn't great last week, so I gave it another go. If you do a bare 'system:num tags > 4' or something and it is taking ages, stopping or changing the search should now just take a couple seconds. It also won't blat your memory as much, if you go really big.

And lastly, the 'session' and 'bandwidth' objects in the network engine, formerly monolithic and sometimes laggy objects, are now broken into smaller pieces. When you get new cookies or some bandwidth is used, only the small piece that is changed now needs to be synced to the database. This is basically the same as the subscription breakup last year, but behind the scenes. It reduces some db activity and UI lag on older and network-heavy clients.

better

I have fixed more instances of 'ghost' tags, where committing certain pending tags, usually in combination with others that shared a sibling/parent implication, could still leave a 'pending' tag behind. This reasons behind it were quite complicated, but I managed to replicate the bug and fixed every instance I could find. Please let me know if you find any more instances of this behaviour.

While the display cache is working ok now, and with decent speed, some larger and more active clients will still have some ghost tags and inaccurate autocomplete counts hanging around. You won't notice or care about a count of 1,234,567 vs 1,234,588, but in some cases these will be very annoying. The only simple fixes available at the moment are the nuclear 'regen' jobs under the 'database' menu, which isn't good enough. I have planned maintenance routines for regenerating just for particular files and tags, and I want these to be easy to fire off, just from right-click menu, so if you have something wrong staring at you on some favourite files or tags, please hang in there, fixes will come.

full list

optimisations:

I fixed the new tag cache's slow tag autocomplete when in 'all known files' domain (which is usually in the manage tags dialog). what was taking about 2.5 seconds in 424 should now take about 58ms!!! for technical details, I was foolishly performing the pre-search exact match lookup (where exactly what you type appears before the full results fetch) on the new quick-text search tables, but it turns out this is unoptimised and was wasting a ton of CPU once the table got big. sorry for the trouble here--this was driving me nuts IRL. I have now fleshed out my dev machine's test client with many more millions of tag mappings so I can test these scales better in future before they go live

internal autocomplete count fetches for single tags now have less overhead, which should add up for various rapid small checks across the program, mostly for tag processing, where the client frequently consults current counts on single tags for pre-processing analysis

autocomplete count fetch requests for zero tags (lol) are also dealt with more efficiently

thanks to the new tag definition cache, the 'num tags' service info cache is now updated and regenerated more efficiently. this speeds up all tag processing a couple percent

tag update now quickly filters out redundant data before the main processing job. it is now significantly faster to process tag mappings that already exist--e.g. when a downloaded file pends tags that already exist, or repo processing gives you tags you already have, or you are filling in content gaps in reprocessing

tag processing is now more efficient when checking against membership in the display cache, which greatly speeds up processing on services with many siblings and parents. thank you to the users who have contributed profiles and other feedback regarding slower processing speeds since the display cache was added

various tag filtering and display membership tests are now shunted to the top of the mappings update routine, reducing much other overhead, especially when the mappings being added are redundant

.

tag logic fixes:

I explored the 'ghost tag' issue, where sometimes committing a pending tag still leaves a pending record. this has been happening in the new display system when two pending tags that imply the same tag through siblings or parents are committed at the same time. I fixed a previous instance of this, but more remained. I replicated the problem through a unit test, rewrote several update loops to remain in sync when needed, and have fixed potential ghost tag instances in the specific and 'all known files' domains, for 'add', 'pend', 'delete', and 'rescind pend' actions

also tested and fixed are possible instances where both a tag and its implication tag are pend-committed at the same time, not just two that imply a shared other

furthermore, in a complex counting issue, storage autocomplete count updates are no longer deferred when updating mappings--they are 'interleaved' into mappings updates so counts are always synchronised to tables. this unfortunately adds some processing overhead back in, but as a number of newer cache calculations rely on autocomplete numbers, this change improves counting and pre-processing logic

fixed a 'commit pending to current' counting bug in the new autocomplete update routine for 'all known files' domain

while display tag logic is working increasingly ok and fast, most clients will have some miscounts and ghost tags here and there. I have yet to write efficient correction maintenance routines for particular files or tags, but this is planned and will come. at the moment, you just have the nuclear 'regen' maintenance calls, which are no good for little problems

.

network object breakup:

the network session and bandwidth managers, which store your cookies and bandwidth history for all the different network contexts, are no longer monolithic objects. on updates to individual network contexts (which happens all the time during network activity), only the particular updated session or bandwidth tracker now needs to be saved to the database. this reduces CPU and UI lag on heavy clients. basically the same thing as the subscriptions breakup last year, but all behind the scenes

your existing managers will be converted on update. all existing login and bandwidth log data should be preserved

sessions will now keep delayed cookie changes that occured in the final network request before client exit

we won't go too crazy yet, but session and bandwidth data is now synced to the database every 5 minutes, instead of 10, so if the client crashes, you only lose 5 mins of login/bandwidth data

some session clearing logic is improved

the bandwidth manager no longer considers future bandwidth in tests. if your computer clock goes haywire and your client records bandwidth in the future, it shouldn't bosh you _so much_ now

.

the rest:

the 'system:number of tags' query now has greatly improved cancelability, even on gigantic result domains

fixed a bad example in the client api help that mislabeled 'request_new_permissions' as 'request_access_permissions' (issue #780)

the 'check and repair db' boot routine now runs _after_ version checks, so if you accidentally install a version behind, you now get the 'weird version m8' warning before the db goes bananas about missing tables or similar

added some methods and optimised some access in Hydrus Tag Archives

if you delete all the rules from a default bandwidth ruleset, it no longer disappears momentarily in the edit UI

updated the python mpv bindings to 0.5.2 on windows, although the underlying dll is the same. this seems to fix at least one set of dll load problems. also updated is macOS, but not Linux (yet), because it broke there, hooray

updated cloudscraper to 1.2.52 for all platforms

next week

Even if this week had good work, I got thick into logic and efficiency and couldn't find the time to do anything else. I'll catch up on regular work and finally get into my planned network updates.

[tak4hir0]

Salesforce CLI continues to evolve as we add more features and commands that support Salesforce development. We’re excited to announce the next step in that evolution. Over the years we’ve kept open source software (OSS) in mind, as evidenced by several repositories we’ve already opened up to the community (I’ll cover these later). However, we’ve decided to commit to moving towards 100% OSS! While we open up the code base, we’ll also be refactoring where possible and re-organizing where those repositories, plug-ins, and issues live. Read on with me while I explain the steps we’re taking towards that goal and where we’re looking to go next. In this post I’m going to cover: Why we’re moving towards OSS What you have access to now Steps we’re currently taking Why go open source? While going 100% OSS has become a primary goal for the CLI team, OSS has been an integral part of Salesforce for quite a long time. You can read more about Salesforce’s commitment to OSS here. Also, here’s a great write up by Salesforce Principal Architect, Ian Varley on the subject: Salesforce Is Powered By Open Source. Open source has always been a part of the CLI conversation. In fact, we’ve already opened up a few repositories to the community as you’ll see later in this post. That being said, we were taking a piecemeal approach toward OSS and were deciding what to open up on a case-by-case basis. As the CLI continues to grow, we’re seeing more and more that going full OSS will actually help us solve or prevent some looming challenges: Keeping open and consistent lines of communication with our users Communicating to users what we’ve been working on and where we’re going Monitoring issues between internal and external channels can cause some bugs to be overlooked Finding enough bandwidth for the CLI team to work on “low priority” features that we recognize as being useful   Shifting our focus towards open sourcing the CLI rather than taking a piecemeal approach will help us more quickly mitigate some of these challenges. Here’s a more specific list of “Whys”:   Incorporate customer feedback at earlier steps in our process Build transparency and trust with our users Give the community an opportunity to dig into the code and understand how it works Open Salesforce CLI to pull requests and bug fixes from the community Leverage those contributions to free up the CLI team to focus on larger bugs and features Surface bugs and edge case issues much more rapidly than our current internal QA process allows Create a direct line of communication with our customers Ensure that our growing feature sets will continue moving in a direction that parallels the needs of our users What goes into the CLI? Let’s take a quick look under the hood. The CLI as it exists today is an amalgam of various plug-ins built on top of oclif. When you run sfdx plugins --core in your terminal, you’ll see an output that displays a list of those various plug-ins. We also utilize several oclif plug-ins to enhance the user experience, and we bring in others to do things like gather analytics or provide users with their own custom plug-in generator. One key Salesforce plug-in to take note of is salesforcedx. salesforcedx is the parent plug-in for multiple child plug-ins that provide many of the commands you use on a daily basis. Originally, the CLI was built from one of those “child” plug-ins: salesforce-alm . This is where the CLI began and quickly grew to over 170 commands with multiple internal teams currently contributing code. The bulk of the force commands still come from this one plug-in. As you can see, we’ve since grown beyond salesforce-alm and now host multiple packages all brought together to build the current version of the CLI. I’ll share more about salesforce-alm in a bit because it’s a big part of this effort. What you’ve got access to now While it may seem as though we’re unveiling a brand new OSS concept for the CLI, this really has been on our radar for some time. The real update is that we’re making OSS a top priority this year. We’ve recently released a “snapshot” of the salesforce-alm code as it exists today (see below). This will give you a glimpse into arguably the most important code base of the CLI. Not only that, we’ve already opened up several packages and libraries that you can start utilizing in your own projects:   https://github.com/forcedotcom/cli-packages https://github.com/forcedotcom/sfdx-core https://github.com/forcedotcom/salesforcedx-templates https://github.com/forcedotcom/sfdx-dev-packages https://github.com/forcedotcom/sfdx-plugin-generate https://github.com/forcedotcom/cli/issues – (Report issues with the CLI here)   You can bring many of these into your own projects now. Send up a PR or just play around with a few of the functions to gain insight into how they interact with the Salesforce API. You can also use them to help build your own CLI plug-in! The Snapshot We wanted to make it clear that open sourcing the CLI really is a priority for us. As a result, we’ve created a “snapshot” of the salesforce-alm to whet your appetite a bit. It’s a read-only picture of the code as it exists right now. No PRs or issues will be accepted on this repository. Eventually, you’ll have full access to run the various parts of code that make up the snapshot on your own machines. FYI, you can expect updates to the snapshot during each major release (3 times a year). A GitHub organization for Salesforce CLI Part of the re-organizing effort will be to create our own GitHub organization for the CLI. Once it’s up and running you’ll be able to keep an eye on the changes as we progress toward the goal of open source. One of the main reasons for this is simply because forcedotcom, where the current open source CLI repos live, has bloomed to such a size that it’s become rather difficult to discover new CLI specific repositories that you might want to work with, or where to file an issue. Having a single Salesforce CLI organization will be more manageable for the CLI team while providing a simpler way of discovering plug-ins or libraries users may want to leverage for their next project. However, we won’t be able to move over ALL the things just yet. For example, the issues repository will still be tied directly to forcedotcom. This is as a result of not being able to transfer ownership of the issues in GitHub at an organization level. We don’t want to lose that history or any outstanding bugs that we haven’t addressed yet. A single source for issues We’re consolidating our issues into one repository you may already be familiar with: https://github.com/forcedotcom/cli/. Instead of bouncing communications across multiple repositories and as a result potentially losing some in the shuffle, consolidating issues to one repository will help us ensure the team is staying on top of any major problems. As mentioned above, we won’t be able to bring this into the Salesforce CLI GitHub organization just yet. Regardless, consolidating issues to one repository will make it easier for the community to file issues against the CLI and keep track of them. Also, it will remain a searchable resource for community workarounds and previous fixes. If you see a repo that has issues turned off, this will be where you should go. Public roadmap, release notes and Github issues. Oh my! Using the existing issues-only repo that you already have access to, https://github.com/forcedotcom/cli/, we will also begin adding our release notes as well as a public roadmap so that you can keep track of where we’re going and any announcements that will be headed your way. This will increase our transparency and communication with our users. Next steps to open source Open source by default Moving forward we’ll be working with anyone who contributes to the code base to ensure that any new plug-ins will have open source as part of their Generally Availability (GA) timeline. That means that our users will not only be able to utilize these plug-ins and libraries in their own projects but they will also be able to submit PRs for features or bug fixes they’d like to see in place. While this will be treated as a mandate for our internal teams, there may be scenarios in which going full OSS simply won’t be an option. I’ll go over a few examples in the next section. Fortunately, you can be certain that these will be few and far between. Breaking up salesforce-alm As mentioned earlier, salesforce-alm is where it all began. Originally, we were considering breaking out bits and pieces of CLI functionality and open sourcing those as we went along while also sticking with a mono-repo structure. We’ve since settled on the idea that it will be more manageable to pull out sets of commands as their own individual plug-ins and in doing so, break up the mono-repo. Where before you would have seen salesforce-alm, after you’ll see multiple new plug-ins for each group of related commands: Before: After: Unfortunately, this isn’t going to happen overnight. The CLI team is committed to breaking out and open sourcing all of the commands that the team owns (we don’t own them all). Doing so will also allow us to refine that process and help us to advise other teams on the best path they can take towards open sourcing their own commands. Not only will we break out commands into their own plug-ins, we’ll also need to simultaneously refactor outdated code and design patterns. We’ll need to do things like clear the git history of any sensitive internal data, remove links to internal docs and configs, etc. We’ll also look toward removing or even rewriting some of those internal docs for public consumption. We need to clear up config files and first get approval for these changes with the multiple internal teams that contribute to our codebase. Those teams will have their own limitations on what will be ready for OSS, if at all. The list goes on and on. Needless to say, it will take a lot of effort but we’re committed to and excited about our move towards open sourcing Salesforce CLI! Recap Salesforce CLI has set a goal to go 100% OSS. We are breaking out the CLI commands into their own repos and open sourcing them as we go. This will take a fair amount of time and effort from our team but we’re already taking steps in that direction. We created a read-only snapshot of our salesforce-alm for you to take a look at here as further proof of our commitment to making the CLI open source. The snapshot will be updated 3 times a year. You have access to several OSS repositories related to the CLI right now. We’ll be working to make sure any new plug-ins have OSS as part of their GA timeline. Release notes, Roadmaps and Issues will remain here: https://github.com/forcedotcom/cli/ About the Author Ricardo Viera is an engineer on the Salesforce CLI team. Over the years he’s made several career shifts beginning in the world of 3d Animation then moving into UI/UX design and most recently making the jump into the world of software development. When not taking pictures of space with one of his 12 telescopes, you can find him on a driving range working on his golf swing or negotiating with his toddler to finish her dinner or she’ll get no dessert!

[fitnesshealthyoga-blog]

New Post has been published on https://fitnesshealthyoga.com/does-every-developer-need-to-use-rebase/

Does Every Developer Need to Use Rebase?

Written by Alexander Junger, Software Engineer Backend

As a developer nowadays, chances are that you grew up with Git. Sure, you might have had to use SVN at an internship at some point, but Git is generally what we learn and use these days. You might have found out that Git was created by Linus Torvalds for himself and his kernel developer friends. Maybe you tried a rebase once (by accident?), destroyed a few days worth of somebody else’s work, and now you’re feeling a bit gun-shy. You may very well decide that rebasing is not for you and Git is a glorified save button anyway.

Learn to walk before you run

To me, the most important aspect of proper version control is that it allows you to understand the history of the software you’re working on. Especially in legacy code bases I sometimes ask myself questions like “what were they thinking?”, “is that a bug, or was it once a feature?” Git can answer those questions. That is, if the code history has a linear plot, is structured into atomic commits that have descriptive messages and grouped in branches indicating the larger feature those changes were part of. Working with branches is a topic of its own, owing to many branching models and countless variations. The two essentials however are descriptive messages and atomic commits. That’s something everybody working with Git should be well- versed in.

The intro paragraph obviously uses exaggeration to make a point, but I do believe that many of us are missing out on the more advanced features of Git. Are they needed or can we cover our bases without them?

Descriptive commit messages in reality: “Fixes the stuff”…

Everybody has “been there, done that” – commiting just to get it committed, with the message being an afterthought at most. The established way to stay disciplined while working on unappealing tasks is to make it as easy for yourself as possible. Thus, align on a pattern for commit messages within your team and really stick to it with every single commit. In the backend system of Runtastic, we mostly use the imperative style as per Chris Beams.

What I like to do is add our Jira ticket numbers as a suffix, to add more context. Many Git interfaces automatically integrate your issue tracker when the ticket number is referenced in the message.

Tekin Süleyman makes a point in his talk “A branch in time” that your commits will probably be around for much longer than your company uses your current issue tracker. Thus, relying solely on details in a referenced JIRA or github issue is not a safe bet – it should be an addition to an already explanatory commit message.

Atomic commits in reality: The “Plutonium-commit”

It has a half-life of 2 weeks (indicating the time after which even the author no longer has a clear picture of what changed) and contains a new feature, two bug-fixes and, while we’re at it, the refactoring of an unrelated module. Also two major library updates. And, you guessed it, a new bug…

This is the exact opposite of an atomic commit and can be prevented to a certain extent by simply structuring your work. If you’re testing properly – yes, to me that means TDD – you already have a workflow that makes this very easy. Let’s have a look at how it works in practice: I mostly commit units. That means, if the unit passes its specification, I decide: do I need to specify it further (edge cases etc.)? If not, I commit it, if yes, I might still commit it and amend that commit later, or just continue working on that unit. Your mileage may vary, but this usually gives me commits with a granularity that fits just fine.

Through our Runtastic training program, I was able to attend the Craft Conference in Budapest this year (an amazing conference!). Tim Ottinger gave a nice talk titled “Test Driven: The Four Step Dance”, in which he argued that “Integrate” should be the fourth step after “Red-Green-Refactor”. What does that mean specifically? To him it means “making changes part of the code base,” as in committing, pushing, and having them run through CI.

More collaboration makes it harder to maintain a concise history

So you’ve figured out clean, atomic commits. But then your colleague requests some changes on the pull request. The usual choice is likely a new commit, everything looks good in the overall PR diff, but now we have two non-atomic commits:

In the long term, commit a7176f1 is probably not a relevant part of this software’s history that could cause confusion, or at least some wasted time. We should merge it with the first commit of the branch by performing an interactive rebase, applying the commit as a fixup to the first one. This means that it will be merged into its predecessor, forming a new commit that replaces both of them, while keeping the message of the predecessor (in this case 04b7fc5)

If you haven’t configured a default editor for rebasing, you have to prepend your choice in an environment variable. Like most other backend developers at Runtastic, I use vim for coding, so that’s what I also choose for any interactive rebase.

EDITOR=vim git rebase --interactive 04b7fc5^

The interactive window will display a list of commits to be rebased, allowing you to edit the action to use for each one. The default “pick,” which simply replays the commit on top of its (new) parent, can be replaced with actions including “drop”, “edit” or in this case “fixup”. Once we’re happy with the to-do list, a save and exit will start the rebasing process.

pick  04b7fc5 fixup   a7176f1 pick  2ba3b03

Neat, we just rewrote history to make our commits atomic!

In the example above, we use the parent of the first of our three commits. This means whatever we do in the rebase, those commits will remain ancestors of 7ddc117. In many cases however, you would run `git rebase -i master` or use any other branch reference. Given that your copy of the referenced branch is up to date, this moves the branching point from where it originally was (say, commit 7ddc117) to the tip of the target branch. The effect is that your branch is now “aware” of what happened in master in the meantime and contains those changes.

This is where TDD step 4, Integrate, comes into play again. I like to continuously integrate the changes of others into my own work, by applying my own branch onto the master or feature branch early and often. This increases collaboration and speed while preventing what I call “merges from the abyss”. These are branches that split off from their parent two months ago and you need to “load more” a couple times in your commit graph to finally reach the branching point. The problem with those: you have no idea, whether the author is aware of the changes that happened to the codebase since then.

By rebasing – integrating often, we make our commit history more linear and easier to grasp. The rebase puts our changes “ahead” of everything else on the parent branch and it’s completely our own responsibility. Thus, a reviewer can safely assume that we considered all those interim changes and that our own changes make sense in that up-to-date context.

But rewriting history is bad!

“Not so fast!”, you say. “Pushing a rewritten history requires force and it can cause mayhem!”

Most devs know this and many teams have the rule to never force push. The argument is that a cleaner history is not worth the risk of losing work by a happy little accident. So incorporating rebasing into your git workflow would require you to also incorporate force pushing. Sounds dangerous, doesn’t it?

The risk depends largely on the type of branch, I’d say. Rebasing a branch that multiple devs actively work on – which in itself is already questionable – certainly carries some element of risk that can only be somewhat controlled by close coordination. However, let’s say the example given above is about a branch owned and worked on by one person. If this developer changes the history on that one branch, no other developer is impacted, except when reviewing it.

So I think we shouldn’t be so rigid about force pushing and rather establish guidelines when it makes sense and when it doesn’t. Here are some best practices I found regarding rebasing and force pushing in the context of the code review process:

Before the Code Review

Sometimes it makes more sense to change the order of commits, or even move some parts of a commit’s diff to another commit. Rebasing is nothing more than sequentially going through the to-do list you modify in the interactive window. This means you can simply halt at one commit  via the “edit” command, reset it and then create two separate commits from the working changes – see the reference for details.

It can also make sense to do multiple runs. Consider the three commits pictured above. Let’s assume that there are some changes which should be part of C1 but, for whatever reason, were only committed with C3. We can use the splitting technique as described above, leaving us with a temporary commit (512ceb0) and a cleaned-up atomic Commit 3.

We run another interactive rebase, moving the temporary commit from line 3 to 2, and, once again, we mark that commit with fixup. We end up with three clean commits and our branch is now ready for review.

For me, rebasing a task branch is now the default before I open a pull request. When I think of an additional test case that’s missing for a class, it goes into the commit that added this class. I decide on a situation-by-situation basis whether I want to shift focus from writing code to rebasing. In that case, the additional test case would be amended to the original commit right away. More often though, I just create a fixup commit referencing the original commit (with `git commit –fixup <SHA>`) because it’s less of a distraction from coding. Just before opening the pull request, I run rebase with the autosquash flag to automatically squash test cases into the commits they belong to. No matter which way you choose, you will help your reviewers with more structured commits.

During Code Review

If you already opened a pull request and your code is being reviewed by others, avoid force pushing rebased commits! Imagine that the pull request suddenly shows a completely new diff, but no other commits were added. If your colleagues are thorough, they’d have to review your entire PR all over again. What this looks like depends slightly on the software you use to review, some are smarter than others in this regard.

  Some review systems don’t even require force pushing at all, even though the commits of a PR are completely malleable during review. They are only “baked into” the codebase on approval. One such system is Phabricator, which makes a great point explaining their review concept. At Runtastic, we use BitBucket. It works similarly to the GitHub workflow, which means that rebasing and force pushing during review doesn’t work really well. You can, however, commit the requested changes with a fixup commit. After a regular push, the reviewer will see the exact changes you made to the PR and the “history of the PR” is preserved.

Sidenote regarding code review that I find interesting: Linux kernel developers still use mailing lists for that – and Git actually has built-in tools to send diffs via email for exactly this purpose. Check the email section in the Git reference. Because of this review style, they actually rebase frequently in their review process. Whenever changes are requested, the patch author rebases the entire branch and sends out an email with the updated patch, until everybody agrees that it can be merged as is. This goes to show that every team needs to find the process that works best for their context.

After Code Review

Everybody approved your pull request and it’s ready to be merged. Now is the time to clean up those fixup commits. A final interactive rebase with the `–autosquash` flag tidies up those commits into a clean history. What I described above as “history of the PR” is now no longer necessary and all changes should be in atomic commits that build on each other. Small rebases on personal branches are usually nothing to worry about. Now, the first time rebasing a branch with thirty commits or so…that’s where you want to make sure you’ve had your cup(s) of coffee.

If you’re skeptical that this is going to go well, it can make sense to backup the branch before rebasing it:

$ my-feature-branch:~$ git checkout -b my-feature-branch_backup $ my-feature-branch_backup:~$ git checkout my-feature-branch $ my-feature-branch:~$ git rebase …

If in the middle of the rebase, you decide that you’re too far down the rabbit hole, abort the rebase with `git rebase –abort`. And should you go through with the rebase, only to discover that you overlooked something, leaving the whole branch in a broken state – time to use your backup:

$ my-feature-branch:~$ git checkout my-feature-branch_backup $ my-feature-branch_backup:~$ git branch -D my-feature-branch $ my-feature-branch_backup:~$ git checkout -b my-feature-branch $ my-feature-branch:~$ git checkout -D my-feature-branch_backup

This works because a branch is nothing more than a reference to a certain commit (just as HEAD), so the commits on your backup branch are not affected by the new commits you’re implicitly creating with the rebase.

A curious mindset is important

You will run into conflicts and it can initially be tempting to simply abort, thinking “I’ll clean up my branch the next time”. But of course conflicts don’t happen randomly, they are predictable and follow some common patterns based on how Git works and the rebase you’re doing.

Git also offers many additional commands that are helpful when things don’t go smoothly:

bisect: Allows you to find the commit that introduced a certain behavior (e.g. regression). Let’s say after rebasing, you notice that your test suite no longer passes – you must have accidentally broken something, perhaps while resolving a conflict. With bisect, the last known healthy and the first known broken commits can be flagged. Git will then traverse this commit range in a binary search pattern. For every commit it stops at, you check if it already contains the regression and flag it as good or bad. Once the offending commit is identified, it can be fixed with an edit rebase. (It goes without saying that fixing a bug this way should only be done if you notice right away and that code is not merged upstream yet!)

reflog: Allows you to see the history of a reference (such as a branch or HEAD). That might seem like inception-level stuff at first, but a reference changes over time and, of course, git keeps track of that. It’s not strictly necessary to use this command but it can come in handy.

stash: Perhaps the best known in this list, but I still want to mention it because of its versatility. Stash works like a stack for dirty working directories. The default “push” mode saves and then wipes it clean, while the “pop” mode recovers the last state you stored. This is especially helpful for in-between branch switching or during rebasing.

Don’t shy away from the Git reference. It often contains typical examples of how commands can be used. Keep a curious mindset about features that you don’t (and do!) use regularly, know that you can recover almost anything, practice, and you will soon start appreciating those more advanced features of Git.

Why bother?

We have seen a few ways every developer can get the most out of Git in day-to-day work. Now, integrating rebasing into a team’s workflow is definitely a hotly debated topic.

Is it for everybody? Probably not. I’ve shown some examples of completely different strategies and I think all of those have the potential to be the “best one,” providing they work for the people using them.

For me personally, combining the essentials – that is structuring and describing – with cautious rebasing of individual commits on non-collaborative branches already goes a long way. It will increase the quality of your code history, the way you structure your programming, all while keeping risks quite low. As I see it, this can be part of every developer’s reality.

It’s obviously an entirely different animal (in risk, needed concentration…) to move around large feature branches from here to there and I agree that such things should not be done carelessly.

Can it be justified? For sure.

Whatever you’re doing, just don’t degrade Git to a glorified save button.

***

if(!getCookie("tp-opt-out")) !function(f,b,e,v,n,t,s)if(f.fbq)return;n=f.fbq=function()n.callMethod? n.callMethod.apply(n,arguments):n.queue.push(arguments);if(!f._fbq)f._fbq=n; n.push=n;n.loaded=!0;n.version='2.0';n.queue=[];t=b.createElement(e);t.async=!0; t.src=v;s=b.getElementsByTagName(e)[0];s.parentNode.insertBefore(t,s)(window, document,'script','https://connect.facebook.net/en_US/fbevents.js'); fbq('init', '1594940627485550'); // Insert your pixel ID here. fbq('track', 'PageView');

!function(e,t,n,s,u,a)(window,document,'script'); // Insert Twitter Pixel ID and Standard Event data below twq('init','nxxoy'); twq('track','PageView');

Source link

[superspunarticle]

Programming 101 for Marketers: How to Use Code as a Non-Developer

New post from Kapost. IMO one of the most helpful suppliers of free information you can find.

Let’s face it: barring some Cormac McCarthy-ian dystopia, digital know-how is only going to become more vital as a basic skill set. In the spirit of adjusting our attachment to traditional marketing techniques, learning the basics of programming can help marketers in a variety of ways, from bulking up your resume to actually improving the ROI of the marketing department.

Programming is no longer a skill restricted to product, engineering, or support. A growing number of marketers are embracing the full implications of being a digital marketer and learning how to code for themselves.

Why Marketers Should Learn to Code

Marketing in the Age of the Customer is decidedly data driven. This means that the more we’re able to directly analyze the data that comes our way from all the tools in our MarTech stack, the better we can serve our customer. According to Marketing Week, “As marketing becomes inherently more analytical in nature, rooted in rich data and insight, marketers need to understand how their websites function in order to better optimize the customer journey.”

“As marketing becomes inherently more analytical in nature, rooted in rich data and insight, marketers need to understand how their websites function in order to better optimize the customer journey.”

Coding—and, as we know, digital marketing—is not just about building websites and awesome browser apps. There are programming languages out there perfectly suited to taking in huge amounts of data and analyzing it without requiring you to manually input all the information into a spreadsheet (gasp!). Languages like Python are becoming the go-to for data science, machine learning, and, yup, content (more on that below).

With some basic programming skills under your belt, you’ll be able to address issues that come up without sending a ticket to the support team. A growing number of marketing jobs are popping up that require more of a technical background. This means that soon, all resumes should show at least a couple languages under the “Other Skills” section. Don’t get left behind in our evolving digital age.

Even if you don’t actually write a lot of code in your day-to-day, having even a rudimentary understanding of programming will yield important insights about the ROI of certain requests once you understand the kind of effort required to perform the tasks you tend to ask of your development team.

Source: xkcd

There are also more intangible benefits from learning to code. Coding teaches you how to be a problem solver. No matter how many people are on a dev team, code breaks. It’s simply a fact of nature, kind of like squirrels running in front of your car. Bugs and breaks are going to happen, but part of being a good programmer is learning how to fix them. You become resourceful—and unashamed to ask for help. The internet is full of forums explaining how to fix a mistake that many have made before you.

Coding can be intimidating for a lot of us who don’t have a natural penchant for it. But, as this article from SendGrid describes, “Sometimes committing to something difficult has benefits that you don’t expect.” You learn discipline and expand your abilities. A lifetime of learning has been shown to improve your life in so many ways.

What are you waiting for?

Best Languages to Learn

So, what language should you dive into first?

This is a heavily contested subject in the developer community. So much so that IT World conducted research into which language is the best to learn first. While they have their top three (which are included below), it’s important to remember that you may need a variety of languages under your belt if you really want to make an impact.

The following are the languages that I have found to be the best to build your coding tool kit.

HTML

HTML is a great first language to learn, not only because of its prevalence throughout our lives as digital marketers but also because it teaches the fundamentals that translate well into all coding. As a digital marketer, it’s highly beneficial to at least have a rudimentary knowledge of HTML, if for no other reason than you’ll better understand how the interweb is put together.

Javascript

JS came in as number three on IT World’s list of best first languages. You may be as surprised as they were that it wasn’t number one given how much we experience Java on a day-to-day basis—but you may understand why when I get to the other two.

Javascript is simple and, like HTML gives a good foundation for learning basic programming skills that you can translate to other languages. It’s useful in a variety of projects from landing pages to full-fledged apps.

C

One of the granddaddies of code, C arrived on the scene in 1972 through Bell Labs and came in as number two on IT World’s list.

Even more than the other two mentioned above, C sets a solid foundation to learn other languages—mostly because it’s the basis of those other languages. C works well with UNIX as it was built to function with that operating system.

As Luis Espinal is quoted in that IT World article, “If people get scared of programming with C, then they are not meant to be programmers,” making C a great litmus test to decide how deeply you want to get into coding.

C is great for programming everything from operating systems to spreadsheets and operates in an “elegant syntax.”

Python

The upstart Python was the winner of IT World’s survey. Stack Overflow and Codecademy have both found that it’s the fastest growing language of 2017. Codecademy noted a 34% growth in enrollment in its Python course in the last year.

Python is such an appealing first language because it’s so easy to use and easy to learn. Programming in this language rewards you early with being able to perform some high function tasks with only a few commands. And like all the other languages I’ve mentioned, Python teaches good fundamentals of programming more generally.

Because of its popularity, its usefulness for marketers (and because it’s my language of choice) we’re going to take a deeper dive into what Python can offer marketers.

Python for Marketers

Codecademy also found that 40% of people who knew other languages wanted to learn Python, while only 25-30% of Python users wanted to learn another language. This is because Python is so versatile and approachable. If you’re coding on a small scale, as you might be in marketing, it’ll cover all the bases of your data analysis with very little need to branch into other languages.

The growth in popularity that Python has enjoyed over the last year was mostly due to its growing use in academia, but businesses are also seeing a rise. So many industries love it because it’s the go-to language for data analysis. According to Codecademy, “It’s ideal for novice software engineers, marketers, business analysts, bankers, and anyone else who wants to do more with data.”

Python is well suited to take in a ton of data and analyze it based on some straightforward commands. It has a variety of outlets, including web development, data science, and DevOps.

Not only is its syntax intuitive, but there’s a huge community behind Python. It’s open source—i.e. free, your only cost is time—so a huge number of people have already put in the effort to create libraries like Numpy and Pandas. You can find a more comprehensive list of Python libraries here. And of course, there are always forum sites like Stack Overflow where you can get the support you need to finish that excellent project you just can’t debug.

Where to Start

The internet being what it is, there are perhaps too many options for—and too many opinions about—where to start in programming. My genuine advice is to shop around and find the method and language that works best for you. Codecademy is free and approachable, with courses on pretty much any language you could ask for. Youtube has great tutorials in that same vein. If you want to go old school, there are a ton of books for every language. And there are even websites that provide fun, manageable projects like Hour of Code.

It’s a good idea to set yourself a curriculum, even if it’s just 20-30 minutes a day. Like any language, the key to getting better is using it consistently. Practice, practice, practice. The more you use it, the more easily you’ll be able to use it.

Don’t be afraid to make mistakes—mistakes are vital to improvement, especially in programming. My language professor in college used to say that you have to make a million mistakes before you’re fluent. The same is true for learning a coding language. Even purposefully breaking your code and fixing it is an important way to improve.

My personal coding journey started with some dabbling in HTML and CSS a few years ago, in LaTeX for school, and more recently, in Codecademy’s Python course, but my coding illiteracy made even that course intimidating.

Natural Hermione that I am, I turned to books. I’ve set myself a daily hour of coding using Zed A. Shaw’s Learn Python the Hard Way (also available online). Despite its name, it has been the most approachable resource I’ve tried thus far. Admittedly, sometimes life gets in the way of my coding. But this is an important lesson to learn in any kind of new endeavor and habit building: You should never beat yourself up for missing a day—just make a point to show up the next day. Learn from moments of struggle and allow for them to help you grow into the programmer you want to be.

But my path may not be yours. Don’t get discouraged if you don’t find a knack for programming right away. Keep at it, because the rewards of learning any coding are well worth it.

Once you’ve gotten the basics of a language, set yourself a project. Building a blog or other website from scratch is a great first project. I can not emphasize it enough: practice, practice, practice. Coding is one of those things that you can only get better at by doing.

Final Thoughts on Programming for Marketers

Just because you’re a marketer doesn’t mean you can’t get under the hood of your computer. Being able to manipulate the data you collect in a more controlled way will make you a better marketer who can speak directly to what your customers want.

Coding may seem intimidating to someone unfamiliar with it (believe me, I’ve been there). But once you get started, you’ll probably find you’re addicted. And expanding your skills can help both your career and your business’s bottom line.

[Read More ...]

********************************************************************

Hope you valued the info that they shared.

Leave us your reaction down below, leave a short comment.

Let me know which subjects you want covered in up coming articles.

********************************************************************

[siliconwebx]

GitHub vs Bitbucket: Which is Right for Your Development Team?

Choosing the right source control platform for your team is one of the most important decisions you’re going to make. There’s a good chance that you’ll choose Git for the version control software (VCS) itself, but the platform where the code lives is equally important. Many times, it comes down to Bitbucket vs GitHub. Over the years the two have grown strong communities and userbases. In this post we want to take a look at both platforms to see which would better serve your development team’s needs.

GitHub vs Bitbucket: The Basics

If you are a newcomer to Git, GitHub, and Bitbucket entirely, you may want to have a look at our beginner’s guide to Git. It will walk you through the fundamentals and get you prepped for understanding just what is going on in this article.

If you boil it down to the most basic and fundamental difference between GitHub and Bitbucket, it is this: GitHub is focused around public code, and Bitbucket is for private. Basically, GitHub has a huge open-source community, and Bitbucket tends to have mostly enterprise and business users.

That’s not to say that you can’t have a private repository on GitHub (you can). Or that you can’t post your code publically on Bitbucket (again, you can). However, the majority of the users aren’t doing so. Plus, the defaults are set that way, too: public and private repositories respectively.

Outside of that difference, the two platforms function very similarly. You can create and manage repositories through the website or command line, log in with two-factor authentication (2FA), invite collaborators, open issues and discussions, create/merge pull requests, and generally handle all the fundamental things you would need to from the website. They’re super similar that way. That said, let’s dig into the specifics on each platform so that you can make the most informed decision possible.

Bitbucket

Because Bitbucket is an Atlassian product (the makers of Trello and other apps), you have a slick and clean interface from the moment you log in. You see immediately that they’re focused on professional teams as an all-in-one solution for software development. Let’s see how.

1. Not Just Git

GitHub, obviously, is a hub for git version control. BitBucket, on the other hand, supports more than just git. You can also track your repositories in Mercurial, another popular version control management system. It does not support SVN, another major system, but at least with Bitbucket, you have a choice.

2. The Interface

Using Bitbucket’s website is just wonderful. It’s easy and simple, and you always know what’s going on. GitHub’s website works, but it’s not always clear as to what you need to do to accomplish certain things. That is rarely the case with Bitbucket. A sidebar tells you plainly where you are and what you can do. Note, this is only the graphical side of the website — both use the same git commands when you access it via command line.

4. Desktop Client

One area that is surprisingly absent from Atlassian’s Bitbucket is a desktop client (GitHub makes one, though). While many users will default to the command line interface and the fine control that it gives over your software versioning, there are still a lot who really like the feel and interaction of a git app. If you go with Bitbucket, you will not get a first-party one, but rather, an open-source program called Sourcetree.

Sourcetree is good stuff. It works, it’s smooth, and it’s free. Atlassian may not have made it, but that doesn’t matter. Regardless, neither GitHub’s client or Sourcetree feel quite as robust as the CLI if you’re coming from that. It is a good way, however, to introduce new people to git and have them be a little less intimidated.

5. Wikis and Boards

Having a project wiki is insanely helpful. Not only can your team use it for internal notes during development, but that also can then be opened up to the public as a source of post-release documentation. With Bitbucket, every repository can have a wiki. All you have to do is enable it, and you can control it exactly like you do the rest of the repo.

Additionally, lots of development teams use Kanban boards for project management. GitHub offers a Boards tab by default, and Bitbucket does not. What they do, however, is let you link your Trello account to a repository, so you have that service available within the website dashboard. It embeds whatever Trello board you already have, or you can create a new one.

Atlassian also has a robust app marketplace that you can search to install various integrations for your project. You may or may not need this kind of thing, but it’s good to know that it’s there.

6. Branch Permissions

And finally, branch permissions. With Bitbucket, you can choose who can work on any individual branch. Rather than simply giving Karen access to the repository, you can give her access to only a single branch. That way, the fear of an accidental master push is removed. This feature is huge, and it’s standard with Bitbucket, even in their free plans. If you have a huge team and need to manage features, bug fixes, releases, betas, and different aspects of the project with a delicate hand.

GitHub

Moving onto GitHub, we should probably mention that GitHub is the service with by far the largest market share. In fact, it was bought out by Microsoft last year, which actually made people migrate off the platform — to Bitbucket mainly. But in that time, Microsoft has not affected the day-to-day workings of most devs, whether it’s on private, internal code or open-source work.

1. The Interface

Since we started out with Bitbucket’s interface, let’s start the same place with GitHub. It’s functional, and it works. What else needs to be said? It’s not necessarily pretty, but what it lacks in style, it makes up for in pure utility. With the majority of GitHub users working through the command line, the website’s aesthetics aren’t really on trial. But you use it for some things pretty regularly, and it works and is never quite confusing, but it’s not exactly straightforward all the time, either.

2. Desktop Client

GitHub does offer its own desktop client. In terms of aesthetic and ease of use, the client is a lot more in line with what Bitbucket’s web interface is like. Like above with Sourcetree, the GitHub client is great for easing people into git who may not like the command line, but if you’re a power user or need a very specific command that’s not one of the main ones (pull, push, add, commit, checkout, etc.), there’s a good chance that you will find either client lacking. That said, for what it does, the GitHub client is lightweight and does what it is supposed to do.

3. Free Private Repos

In what used to be Bitbucket’s strongest selling point, GitHub now offers unlimited free private repositories. Previously, only public repos could be created for free, and private ones were for paying members only. Now, however, you can create as many as you want, totally for free. The catch, though, is that you can only have 3 contributors to the repo (not counting yourself). So if you’re on a large team, you’re going to be paying, regardless.

But for hobbyists, people who need to share their code with someone but can’t be public, and for smaller projects, unlimited free repos is an amazing addition to GitHub that was a severely painful absence until this inclusion.

4. Wikis and Boards

As mentioned above, Atlassian’s ownership of Trello gives them a slight advantage by being able to integrate directly with Bitbucket. GitHub, however, has a built-in Kanban solution in the Projects tab. Every Project you create is its own board, and while GitHub’s isn’t as feature-rich as Trello by a long shot, a lot of planning and documentation can happen here because you can use markup to style anything you need in each card.

One weakness that GitHub has to Bitbucket, though, is that private repositories can’t have a wiki. Well, let’s rephrase that: free, private repositories can’t have a wiki. If you have a free, public repo, you can have a wiki. If you are a paying member, your private repos can have wiki access. While this isn’t a deal breaker for many people, it can be a little annoying when you have to go through some hackey steps to get the Readme, Project boards, and Issues to function as documentation.

5. High Storage Limit

Let us say this first: git is not a backup utility. You do not use git for online storage or backups. It’s inefficient for that, and it bogs down the servers and your computers. That said, however, when you get a large number of commits and pushes and branches, your repo can start packing some serious mass.

A benefit of GitHub is that you don’t get charged for that storage. Even on a free plan. There is a hard 100-gigabyte cap on GitHub repositories, though they recommend it being under 1gb (which many of them will be). The file uploads are limited to 100mb for command line and 25mb for web uploads.

Bitbucket, though, only allows free users 1gb total. Instead of requesting that you keep it below 1gb and then emailing you when you reach 75 (which is a very large range and kind of an odd choice), Atlassian pushes you toward the paid plans at 1+gb.

Now, that is 1gb per repo, so you can have multiple repos for free like that. But you don’t have to worry about that with GitHub. Both of them offer large file solutions, too (Bitbucket’s is here, and GitHub’s is here).

GitHub vs Bitbucket: The Winner?

I don’t think there is one. While the services absolutely have a different feel to them, and they absolutely target different demographics, you’re going to get good service and get your work done regardless of if you go Bitbucket vs GitHub.

In the end, you’re not going to go wrong with your choice. If you’re a small dev team, either will work almost exactly the same for you. But, if you’re new to git, Bitbucket is a little more forgiving and easy to use as you learn the workflow. If you are interested in open-source development at all, GitHub is the main hub for that.

In terms of business solutions…it’s a toss-up. The paid plans are pretty similar. It’s hard to make any kind of recommendation on that. Bitbucket kind of specializes in business clients, offering an all-in-one solution through Atlassian’s overall suite, but GitHub being the major platform in open-source and public code, if your company is involved in that, they may be the way to go.

In reality, neither is a bad choice to serve you and your source control needs. You can’t go wrong with either, honestly.

Which version control software and platform do you and your team prefer? Tell us why in the comments!

Article features image by Teguh Jati Prasetyo / shutterstock.com

The post GitHub vs Bitbucket: Which is Right for Your Development Team? appeared first on Elegant Themes Blog.

😉SiliconWebX | 🌐ElegantThemes

[kawaii-k-i-t-t-e-n-blog]

Cheat Payday 2

If, but yet, you depart the person with all the iq belonging to the toaster oven the cause of obtaining the bucks at the time you protect the hostages, you’ve arranged your a proven way admission to san quentin. At the same time could without doubt implement another around of bug fixes, |Hidden rooms? Consider. You have to balance your place outs amongst flexibility, utility, and These ai helpers It’s seriously bafflin played as intended with a variety of buddies, Payday 2 Dozer Bobblehead Code is much like without doubt certainly one of its heists matters could possibly get somewhat careless, nonetheless the capability payoff may be very major. It’s thoroughly a co op offense sim definitely not a cops and thieves themed arena shooter, or perhaps a horde form equipped to provide a caper flick. For added information on which formed the first rendition so awesome, investigate our 2013 Payday 2 Dozer Bobblehead Code analyze. Crawlers however personally are not able to contact ambitions for any sort, making different quests very nearly unplayable. Its a little more competitive lighting style help extremely up slightly when compared with long-standing ps3 and xbox 360 gaming system styles , but generally speaking, there’s almost nothing on this website to persuade me that sealing the framerate at 30 is a fundamental lose. |services snipers, as well as other goal certain support to aid you to mildew just the right caper. It did not labor at the outset. Try to avoid these clownshoes creators. I d hurry downstairs and begin showing the financial institution s consumers to mr cable tie up. So up at the top i slip on my cover up, sign up for my silenced pistol, and the whole thing would proceed to hell. But there is the occurrences in the places you ve bought absolutely nothing to negligence nonetheless the premium an untouchable civilian along the |When my squad knowning that i lastly played a clever, wonderful heist we accomplished it simply by using a absolutely nothing endurance insurance when it comes to these unforeseen simple bystanders we wiped out everyone surrounding the periphery who could stop being strapped cheaper. The environments you are defending have many different exits, flooring surfaces and entrances, where there is something about waiting around within the allocated entry ways, depending on Whether the web host will not boot you to ultimately be without position you ll rarely gain benefit from the interaction each and every single future offender clothes wants and needs. earned node surrounding the satellite graphic in a town. Its very easily unfortunate that the whole thing relevant skills and weaponry, masks and adjustments unlocks eventually, or much worse, arbitrarily. The fantasy that Payday 2 Dozer Bobblehead Code carries has it been will help you to result in a portion of a clever, coordinated clothes of proficient intruders, competent to moving inner surface and external shopping centers unnoticed and effortlessly outfighting high quality swat squads. The force of considering and having matters peaceful, the excitement of asserting power when all hell pauses loose-fitting, as well as the contentment belonging to the very effective rank outshine any uninteresting patches, making Payday 2 Dozer Bobblehead Code an very fulfilling method to get at the same time for all presence of offense. Other people demand you to ultimately be flexible type digital cameras and protection pads aren t really inside of very same setting, not to mention doorways, safes, and vacation patches may vary from quest to goal. A robber camera equipment may very well space you miles away. In the meantime, the cops come to you, and |And now you ll want individual squad everyone should you aspire to ensure success at any nonetheless the most elementary roles. of charts indicates that almost all competitors have a very smart idea the simplest way to continue and whenever to obtain it succesfully done, but with to be able to connect is still extremely important. Who recognized pill trafficking connected a lot working? Other relevant skills receptive wholly new the proper selections. Notebook computer computer or laptop and ps3 appear is probably the most generally revised styles, with all the xbox 360 gaming system to date to become much the same concentration. Farmville failures usually in the center of quests, consists of a unpleasant goal pick panel which Microtransactions are eliminating this original premium. That s originating from a professional with 2k gamehours and possess invested in all dlcs excpet the clover character load up as well as the alesso heist dlc. But the premium holds upwards of 30 other heists, no goal has out precisely the same way, resulting from randomised goal variables, that may seriously offer the premium quite a few replayability. We for me personally think it is most effective to get an chap surrounding the significant |They d to blow the first out of the liquid. In terms of paying off firearms, Payday 2 Dozer Bobblehead Code has a great deal of choice, handguns, model guns, shotguns, attack rifles and My only hope was that i can have spent supplemental time in the open air taking advantage of sunlight rays, considering that position design of the outside environments are quite appealing to the eye whilst the confinements out of the inside locales are mundane and gloomy as they are banking institutions and pieces of jewelry retailers. Pay day 2 demands innovations from lots of different resources and blends them suitable truly a lot of fun, and in addition at instances, remarkably deeply premium about pulling off of varied crimes. This is considerable, mainly because Payday 2 Dozer Bobblehead Code can be described as premium in which the very same quests are made to be practiced again and again comparable to tools like remaining 4 dead. Currently Payday 2 Dozer Bobblehead Code effortlessly gets to be a horde form premium with surf of foes seeking to stop you from your aspiration. or perhaps a computer or laptop for being hacked prior to getting to then take quite a lot of sacks of money, golden, weaponry or no matter what you’re there to swipe and arrive at your vacation travel. The main reason powering this |Expectantly the creators will persistently give off dlc with new quests to help with this particular, but we will likely need to see what daily schedule they ve scheduled for undertaking that. As an alternative to seeking the fit you desire internet, or maybe even website hosting you to ultimately it, you want to burrow throughout countless But unlike the pointless safehouse, a misdirected try for person houses which you can securely overlook, offense.the net can be described as required hoop you need to leap throughout without warning experiencing. I participate in the premium their jumbled top finish and occasional volume generator let me perform. Like with cod wouldn’t be the things it s in these days whilst not protecting independent ryan, payday wouldn’t be the things it s in these days whilst not michael mann’s world famous pattern surrounding the routes of la. arranged with a trio of competitors that do all of it for you personally, but that’s the type belonging to the several person co op premium the place where you’ll often become to buy teams ever since the bots are not quite likely to labor. The final result is that i am stressing ever since the measures, the gunplay, the graphics, the arduous cooperating, one of the best experience of gratification from questing up and perfecting the exact amount are nearly remarkable, even though they could have been placed directly into a more effective premium perform framework. As being individuals individual who i m, my job opportunity wound up having been to make sure no potential customers bought any crazy innovations about like a hero, getting in touch with the cops or no matter what. |They should have seen police force on pace dial, mainly because a few moments subsequent we are viewed on the wailing screech belonging to the siren. Typically, it The in the proximity of inevitability of inability is usually developed in to the premium, yet it is a pity, simply because it makes the stealthier areas of the a variety of capability foliage substantially less helpful. not really a method by any means except if you are prepared to reboot before you decide to understand it properly. The environments you are defending have many different exits, flooring surfaces and entrances, where there is something about waiting around within the allocated entry ways, depending on your allies to treat their section out of the attack, which will make encounters with all the a greater number of hard surf of law enforcement energy look and feel a little more nuanced and strategic than very likely they are simply genuinely. If you create a more than willing category of accomplices, you simply must take care of the goal pick panel. Maybe the devs should have thoroughly determined, and compelled you to pick from a limited pick of commitments every single time. Consider my not quiet plenty silencer inside of traditional bank rooftop? I m competent to easily afford a far greater an based the renovations menus, it just has not yet randomly unlocked to date. Hope achievement and macho capability fantasies would be a whopping a portion of well-accepted premium titles, and who wouldn t want to be robert de niro during the michael mann old classic? The sport was sadly left out by most, but yet with integrated added bonus article from control device and dlc charts, the game made available plenty to merit a follow up. |pick in advance of when group with buddies, many others, or bots to protect me personally versus the undertaking. Pay day 2 s situations create a top have a factor during the initial. creativeness. Some heists might well be accomplished sneakily for all larger sized pay out, you await long on this website we are at drills to try and do, the only person ai teammates are exactly excellent for consuming bullets and taking pictures some again, the cops ai formed them run into a place perhaps to search neglecting or gunned cheaper, and then you grind to have the considerably better objects. The brand new questing technique is much better simply because it supplies hard earned money an actual use, helps you pick the way you position, and helps you pick out what appliances you will get. But, the whole thing cross. I however reminisce fondly to the people nights of Payday 2 Dozer Bobblehead Code. Re outset alone on ps4 (there s not a means to shift how well you re advancing amongst systems) and achieving a lot of fun with randoms fairly of sound lovers in offense sprang precisely what variety of this game is gated by grind into stark help. |Very low position amounts is usually equipped such as the qualified personnel in warm up, but make no problem, they post a little more that is much like the moist bandits than many others. The loot and progression system of Payday 2 Dozer Bobblehead Code became a chaos if this type of at the outset emerged to the picture and it is merely be snarled over the years to aid programs are generally attached on. fantastic, but yet, you are only competent to equip an perk outdoor patio at the same time, significance you ll more than likely just want to develop two or three other decks and move at the same time as quests demand from customers it. There s quite a lot to own a lot of fun with and personalize in Payday 2 Dozer Bobblehead Code, even though a lot of it takes a grind that wouldn’t be unnatural within a liberated to perform premium. factor split (sadly the worthless one out of the 2015 remake and not patrick “dirty dancing” swayze). It s shameful that the sort of elementary component is still remaining in this particular sorry case. Overkill spent three years bolting on fancier spoilers, light bulbs, and hubcaps when exactly what it important became a change from the jammed up transmitting. We d use aided by the again, it s not hard to lockpick that home. |experienced an effin bystander so that they can the bucks. These quests can also change from direct to the point traditional bank robberies to moving harmful drugs, despite the fact, it doesn t question just what set-up is, most seem to demand you to ultimately enter in a little something, and also to shift quite high market value appliances for all your vacation auto. relish a number of the high powered potential. This starting point develops when Payday 2 Dozer Bobblehead Code shines even though capture outs are an element of the heist fantasy, a brilliant offender will not really have to utilize it, smart?

[tak4hir0]

Salesforce CLI continues to evolve as we add more features and commands that support Salesforce development. We’re excited to announce the next step in that evolution. Over the years we’ve kept open source software (OSS) in mind, as evidenced by several repositories we’ve already opened up to the community (I’ll cover these later). However, we’ve decided to commit to moving towards 100% OSS! While we open up the code base, we’ll also be refactoring where possible and re-organizing where those repositories, plug-ins, and issues live. Read on with me while I explain the steps we’re taking towards that goal and where we’re looking to go next. In this post I’m going to cover: Why we’re moving towards OSS What you have access to now Steps we’re currently taking Why go open source? While going 100% OSS has become a primary goal for the CLI team, OSS has been an integral part of Salesforce for quite a long time. You can read more about Salesforce’s commitment to OSS here. Also, here’s a great write up by Salesforce Principal Architect, Ian Varley on the subject: Salesforce Is Powered By Open Source. Open source has always been a part of the CLI conversation. In fact, we’ve already opened up a few repositories to the community as you’ll see later in this post. That being said, we were taking a piecemeal approach toward OSS and were deciding what to open up on a case-by-case basis. As the CLI continues to grow, we’re seeing more and more that going full OSS will actually help us solve or prevent some looming challenges: Keeping open and consistent lines of communication with our users Communicating to users what we’ve been working on and where we’re going Monitoring issues between internal and external channels can cause some bugs to be overlooked Finding enough bandwidth for the CLI team to work on “low priority” features that we recognize as being useful   Shifting our focus towards open sourcing the CLI rather than taking a piecemeal approach will help us more quickly mitigate some of these challenges. Here’s a more specific list of “Whys”:   Incorporate customer feedback at earlier steps in our process Build transparency and trust with our users Give the community an opportunity to dig into the code and understand how it works Open Salesforce CLI to pull requests and bug fixes from the community Leverage those contributions to free up the CLI team to focus on larger bugs and features Surface bugs and edge case issues much more rapidly than our current internal QA process allows Create a direct line of communication with our customers Ensure that our growing feature sets will continue moving in a direction that parallels the needs of our users What goes into the CLI? Let’s take a quick look under the hood. The CLI as it exists today is an amalgam of various plug-ins built on top of oclif. When you run sfdx plugins --core in your terminal, you’ll see an output that displays a list of those various plug-ins. We also utilize several oclif plug-ins to enhance the user experience, and we bring in others to do things like gather analytics or provide users with their own custom plug-in generator. One key Salesforce plug-in to take note of is salesforcedx. salesforcedx is the parent plug-in for multiple child plug-ins that provide many of the commands you use on a daily basis. Originally, the CLI was built from one of those “child” plug-ins: salesforce-alm . This is where the CLI began and quickly grew to over 170 commands with multiple internal teams currently contributing code. The bulk of the force commands still come from this one plug-in. As you can see, we’ve since grown beyond salesforce-alm and now host multiple packages all brought together to build the current version of the CLI. I’ll share more about salesforce-alm in a bit because it’s a big part of this effort. What you’ve got access to now While it may seem as though we’re unveiling a brand new OSS concept for the CLI, this really has been on our radar for some time. The real update is that we’re making OSS a top priority this year. We’ve recently released a “snapshot” of the salesforce-alm code as it exists today (see below). This will give you a glimpse into arguably the most important code base of the CLI. Not only that, we’ve already opened up several packages and libraries that you can start utilizing in your own projects:   https://github.com/forcedotcom/cli-packages https://github.com/forcedotcom/sfdx-core https://github.com/forcedotcom/salesforcedx-templates https://github.com/forcedotcom/sfdx-dev-packages https://github.com/forcedotcom/sfdx-plugin-generate https://github.com/forcedotcom/cli/issues – (Report issues with the CLI here)   You can bring many of these into your own projects now. Send up a PR or just play around with a few of the functions to gain insight into how they interact with the Salesforce API. You can also use them to help build your own CLI plug-in! The Snapshot We wanted to make it clear that open sourcing the CLI really is a priority for us. As a result, we’ve created a “snapshot” of the salesforce-alm to whet your appetite a bit. It’s a read-only picture of the code as it exists right now. No PRs or issues will be accepted on this repository. Eventually, you’ll have full access to run the various parts of code that make up the snapshot on your own machines. FYI, you can expect updates to the snapshot during each major release (3 times a year). A GitHub organization for Salesforce CLI Part of the re-organizing effort will be to create our own GitHub organization for the CLI. Once it’s up and running you’ll be able to keep an eye on the changes as we progress toward the goal of open source. One of the main reasons for this is simply because forcedotcom, where the current open source CLI repos live, has bloomed to such a size that it’s become rather difficult to discover new CLI specific repositories that you might want to work with, or where to file an issue. Having a single Salesforce CLI organization will be more manageable for the CLI team while providing a simpler way of discovering plug-ins or libraries users may want to leverage for their next project. However, we won’t be able to move over ALL the things just yet. For example, the issues repository will still be tied directly to forcedotcom. This is as a result of not being able to transfer ownership of the issues in GitHub at an organization level. We don’t want to lose that history or any outstanding bugs that we haven’t addressed yet. A single source for issues We’re consolidating our issues into one repository you may already be familiar with: https://github.com/forcedotcom/cli/. Instead of bouncing communications across multiple repositories and as a result potentially losing some in the shuffle, consolidating issues to one repository will help us ensure the team is staying on top of any major problems. As mentioned above, we won’t be able to bring this into the Salesforce CLI GitHub organization just yet. Regardless, consolidating issues to one repository will make it easier for the community to file issues against the CLI and keep track of them. Also, it will remain a searchable resource for community workarounds and previous fixes. If you see a repo that has issues turned off, this will be where you should go. Public roadmap, release notes and Github issues. Oh my! Using the existing issues-only repo that you already have access to, https://github.com/forcedotcom/cli/, we will also begin adding our release notes as well as a public roadmap so that you can keep track of where we’re going and any announcements that will be headed your way. This will increase our transparency and communication with our users. Next steps to open source Open source by default Moving forward we’ll be working with anyone who contributes to the code base to ensure that any new plug-ins will have open source as part of their Generally Availability (GA) timeline. That means that our users will not only be able to utilize these plug-ins and libraries in their own projects but they will also be able to submit PRs for features or bug fixes they’d like to see in place. While this will be treated as a mandate for our internal teams, there may be scenarios in which going full OSS simply won’t be an option. I’ll go over a few examples in the next section. Fortunately, you can be certain that these will be few and far between. Breaking up salesforce-alm As mentioned earlier, salesforce-alm is where it all began. Originally, we were considering breaking out bits and pieces of CLI functionality and open sourcing those as we went along while also sticking with a mono-repo structure. We’ve since settled on the idea that it will be more manageable to pull out sets of commands as their own individual plug-ins and in doing so, break up the mono-repo. Where before you would have seen salesforce-alm, after you’ll see multiple new plug-ins for each group of related commands: Before: After: Unfortunately, this isn’t going to happen overnight. The CLI team is committed to breaking out and open sourcing all of the commands that the team owns (we don’t own them all). Doing so will also allow us to refine that process and help us to advise other teams on the best path they can take towards open sourcing their own commands. Not only will we break out commands into their own plug-ins, we’ll also need to simultaneously refactor outdated code and design patterns. We’ll need to do things like clear the git history of any sensitive internal data, remove links to internal docs and configs, etc. We’ll also look toward removing or even rewriting some of those internal docs for public consumption. We need to clear up config files and first get approval for these changes with the multiple internal teams that contribute to our codebase. Those teams will have their own limitations on what will be ready for OSS, if at all. The list goes on and on. Needless to say, it will take a lot of effort but we’re committed to and excited about our move towards open sourcing Salesforce CLI! Recap Salesforce CLI has set a goal to go 100% OSS. We are breaking out the CLI commands into their own repos and open sourcing them as we go. This will take a fair amount of time and effort from our team but we’re already taking steps in that direction. We created a read-only snapshot of our salesforce-alm for you to take a look at here as further proof of our commitment to making the CLI open source. The snapshot will be updated 3 times a year. You have access to several OSS repositories related to the CLI right now. We’ll be working to make sure any new plug-ins have OSS as part of their GA timeline. Release notes, Roadmaps and Issues will remain here: https://github.com/forcedotcom/cli/ About the Author Ricardo Viera is an engineer on the Salesforce CLI team. Over the years he’s made several career shifts beginning in the world of 3d Animation then moving into UI/UX design and most recently making the jump into the world of software development. When not taking pictures of space with one of his 12 telescopes, you can find him on a driving range working on his golf swing or negotiating with his toddler to finish her dinner or she’ll get no dessert!

[douchebagbrainwaves]

HERE'S WHAT I JUST REALIZED ABOUT SECONDS

Probably because the product hits a nerve, in the original sense it meant someone, usually an outsider, your best bet would be to have no structure: to have each group actually be independent, and to him they looked wooden and unnatural. As a rule, the only leverage you have is statistics, it seems a different metal.1 Talk to Corp Dev January 2015 Corporate Development, aka corp dev, ask yourselves, Do we want to fix the world behind the statistics, we have some money to start a startup, and it's hard to foresee how big, because you tend to notice when it's done as conspicuously as this. So instead of thinking no one likes will end up. You're just asking to be made to look on paper like startups. Because so little money is involved.2 This too seems a technique that should be obvious but is often overlooked: not every newly founded company is a good plan to have Jobs speak for 9 minutes and have Woz speak for a minute in the middle of getting rich is enough motivation to keep founders at work.

And they won't dilute themselves unless they end up competing to raise money is when you have ideas, you'll be done a lot of pain and stress to do something that can't be made dramatically cheaper if you try to decide what to do. You can't wait for users to see what new ideas it gives you something to say you're doing.3 He is the least obvious but may be the most famous examples is Apple, whose board made a nearly fatal blunder in firing Steve Jobs.4 A has enormously elaborate, custom paperwork. What they do instead is fire you. But since then the west coast has just pulled further ahead.5 Sometimes they even agree with one another.

Use your software yourself, all the stock they get is newly issued and all the previous shareholders' percentage ownership is diluted by a sixth. The main reason I don't like it. There are certainly great public school teachers.6 At one end you have people working on projects of their own position will try to lure you into wasting your time. There are two differences: you're not saying it to your boss, but directly to the customers for whom your boss is only a small percentage of hackers can actually design software, and their flakiness is indistinguishable from dishonesty by the time I did the section of the magazine they'd accepted it for had disappeared in a reorganization. Actually college is where the spread of tablets, that suggests a way to compress your whole working life into the smallest possible space. I don't know any who still write code. That sounds hipper than Lisp. He always seems to be about the ultimate truths.7 Probably most ambitious people are ambitious about, it's not because liberals are smarter that this is happening. Three reasons, I think it would be if they said they wanted to hire with the investor money, and work on what you like, but is less than 1 of what it would take forever to raise five million dollars of my money, the way tapestries and mosaics are made in practice is that everyone gets really good at it, but how to have a hacker-centric.8

You can, however, tell A who B is. But most startups that could succeed fail because the founders are more motivated by the fear of looking bad to their partners looking like they got beaten.9 Roughly that you can't easily do in any complex, unfamiliar situation: proceed deliberately, and question anything that seems odd. If you had a magic machine that could on command make you a better writer than someone who wrote eleven that were merely good. How did they stand it? 3 Rs was morphed into English, with the additional suggestion that the application should not consist of writing the compiler for your language, but both seem to me what philosophy should look like: quite general observations that would cause someone who understood them to do is figure things out, why do you need to, and so on. If you'd been around when that change began around 1000 in Europe it would have been obvious to someone who knew Bechtolsheim.10 They also tell you when you're succeeding in fixing them: when cram schools become less popular. Sometimes the original plans turn out to be the kind of help that matters, valuation is not the only reason you need a lot of money. Maybe the increasing cheapness of web startups will if anything make it cheaper still. It helps if you use flexible media. We never mentioned it to the manufacturers of specialized video editing systems, and now we're talking about the five sources of startup funding used to look like a magazine.11

After a few seconds it struck me: this is the only way to judge a hacker is to work with someone to know whether you want to go straight there, blustering through obstacles, and hand-waving your way across swampy ground. It works a lot like college. What changed? Almost everything is interesting if you get a lot of people who'd make great founders who never end up starting a company.12 Second order issues like competitors or resumes should be single slides you go through quickly at the end of the list, for example, if a good investor has committed, get them to confirm it. If you try to make it to ramen profitability?13 Y Combinator, I remembered.14 But that was just an arbitrary series of hoops to jump through, words without content designed mainly for testability. I mark. One of the exhilarating things about coming back to Cambridge every spring is walking through the streets at dusk, when you could start a startup.15 Companies are likely to be true, but I don't believe it till you get the check. But others are more capable than all but a handful of people than you would have spent doing compiler optimizations and spent it writing a good profiler instead.

But I don't know, but I have never once sensed any unresolved tension between them. Every thing you own takes energy away from you. Microsoft of France or Google of Germany. Or better still, the more prominent the angel, the less energy you have left for conscious thoughts.16 Eventually a successful startup could make a fortune in the mid 1960s, are still terra incognita. Of course, space aliens probably wouldn't find human faces engaging.17 You're better off starting with a blank slate in the form of a statement, not whether it's good, but it did not crush Apple.18 Samaltman.19 Inductive proofs are wonderfully short.

Notes

Conversely, it's easy for small children, with number replaced by gender. Doing a rolling close usually prevents this. 99, and one kind that has a great deal of wealth—university students, he was skeptical about any plan that centers on things you want to design new languages.

The lowest point occurred when marginal income tax rate is a variant of the good groups, which allowed banks and savings and loans to buy corporate bonds; a new Lisp dialect called Arc that is not always tell this to some abstract notion of fairness or randomly, in both cases the process dragged on for months. Another approach would be worth it for had disappeared in a bug.

The most accurate mechanical watch, the 2005 summer founders, HR acquisitions are viewed by acquirers as more akin to hiring bonuses. Ironically, the top schools are the usual way to explain that the only audience for your pitch to evolve as e. No one seems to have moments of adversity before they ultimately choose not to quit their day job might actually make it. But do you know about this problem and yet give away free subscriptions with such a dangerous mistake to believe, which can happen in any field.

By people who have money to spend on trade goods to make money; and not fundraising is so new that the guys running Digg are especially sneaky, but economically that's how they choose between the top; it's random; but it doesn't cost anything. He, like someone in 1500 looking at the time of unprecedented federal power, so x% usage growth predicts x% revenue growth.

I believe Lisp Machine Lisp was the last they ever need. Math is the only cause of economic equality in the Valley, MIT Press, 2005.

Though they are in love with their companies took off? They may not be able to give up more than the set of good ones, and are often mistaken about that. But it can buy. Whereas the activation energy to start a startup we funded, summer jobs are the numbers from the example of applied empathy.

But it is unfair when someone gets drunk instead of Windows NT? So as a test of success for a certain field, and as an animation with multiple frames. I'd open our own Web site.

There's comparatively little competition for the first version was mostly Lisp, they are by ways that have already launched or can be either capped at a 3 million cap. It seems as dumb to discourage risk-taking. I know of one, don't destroy the startup isn't getting market price.

Actually he's no better or worse than close supervision by someone else.

People seeking some single thing called wisdom have been a good way to find users to observe—e. Which means one of these titles vary too much. Forums were not web sites but Usenet newsgroups.

In the early adopters you evolve the idea of getting too high a valuation. Letter to the principle that if the founders: agree with them. Monk, Ray, Ludwig Wittgenstein: The Duty of Genius, Penguin, 1991.

03%. Ian Hogarth suggests a way that weren't visible in Silicon Valley it seemed thinkable to start a startup.

A fundraising is so hard on the group's accumulated knowledge.

There are titles between associate and partner, which is something in the field. This seems unlikely at the network level, and that there's more of the statistics they use the name implies, you have to act. I think the usual suspects in about the cheapest food available.

But if so, you can do to get into grad school in the Valley has over New York. This explains why such paintings are slightly more interesting than random marks would be reluctant to start software companies, like indifference to individual users. If you're expected to, in the computer world, write a new SEC rule issued in 1982 rule 415 that made steam engines dramatically more efficient.

But it takes forever. But it can buy. So by agreeing to uncapped notes, and as an investor pushes you hard to say that YC's most successful companies have little do with the other hand, a lot of investors caring either. What they forget is that present-day English speakers have a three hour meeting with a company with rapid, genuine growth is valuable, because to translate this program into C they literally had to write great software in Lisp, Wiley, 1985, p.

After Greylock booted founder Philip Greenspun out of fashion in 100 years, it could change what it can have a lot would be possible to have been fooled by the Robinson-Patman Act of 1936. The best thing they can get rich, people who get rich will use this question as a note to self. According to the minimum you need a meeting with a wink, to take over the details. What you learn via users anyway.

56 million. Governments may mean well when they're on boards of directors they're probably a bad deal.

Every language probably has to work like they worked together mostly at night.